AWSの責任共有モデル

AWS（Amazon Web Service）はGAFAの一角、Amazon社が展開する世界最大のクラウドサービスです。クラウドサービスはセキュリティ対策も万全で、AWSを利用する上で利用者側は何も意識する必要がないと思われがちですが、それは大きな誤りです。

AWSを利用する場合は、利用者側も障害などに対して一定の責任を負わなければならず、これがAWSの「責任共有モデル」と言われるものです。その責任を理解した上で、必要な対策を講じ、ルールを順守して利用することが求められます。

この記事では、AWSの責任共有モデルとは何か、利用者側の責任範囲はどこまでか、利用に当たって注意すべきことは何かなどについて解説します。

【参考】：アマゾン ウェブ サービス｜AWS クラウド｜ ホーム

AWSとは？メリットや何がすごいのか、初心者にもわかりやすく解説

AWSには独自の「責任共有モデル」（shared responsibility model）があり、わかりやすくいうと、「セキュリティとコンプライアンスはAWSと利用者の間で共有されるべき責任」という考え方に基づいています。

AWSの責任共有モデルは、AWS提供のインフラやサービスの内、AWS責任範囲と、利用者責任範囲を明確に分けています。具体的にはAWSの責任範囲はAWSが提供するハードウェア・ソフトウェア、ネットワークおよびAWSクラウドサービスを提供している施設です。

仮にAWSの責任範囲で事故があり、利用者側が損害を被った場合はAWSが損害賠償責任を負います。一方、AWSが提供するサービス以外の範囲が利用者責任ですが、その責任範囲は、利用者が選択したAWSクラウドサービスによって異なっています。

この責任共有モデルについては、「AWSホワイトペーパーとガイド」※でも詳しく解説されています。

【参考】：責任共有モデル – アマゾン ウェブ サービス｜AWS

【参考】：※AWSホワイトペーパーとガイド | AWS

AWSの公式ホワイトペーパーとは？日本語掲載情報はどこ？

AWSには「Lambda」というサーバレスのFaaS（Function as a Service）のサービスがあります。インスタンスを構築せず、いきなりコードを実行できるサービスですが、このLambdaにも責任共有モデルがあります。

Lambdaでの利用者側の主な責任範囲は、Lambda内にデプロイしたアプリケーションとデータ、そしてインターネットからのアクセスです。詳しくは「AWS Lambda のセキュリティの概要」に記されています。

【参考】：※AWS Lambda のセキュリティの概要-Security Overview of AWS Lambda_JP.pdf｜AWS

AWS Lambdaとは？できることを分かりやすく解説！

AWSをはじめとして、クラウドサービスは堅牢なセキュリティ対策を講じています。クラウド事業者側に起因する大規模な事故が起きれば、クラウドビジネスそのものが否定されかねないからです。

その結果、クラウドサービスにおけるセキユリティ事故の大半は、クラウド事業者側ではなく利用者側の人的なミスによって起きていると言われています。

主なものとしては、リモート操作で利用するSSH（Secure Shell）のポートの閉じ忘れによる不正ログイン、ストレージサービスのバケット開放による情報漏洩、IAM ユーザーやAWSアカウントルートユーザーのアクセスキー漏洩などが挙げられています。

個人情報の漏洩が起きると、その影響範囲は自社のみならず顧客全体に及び、その結果として企業の信用失墜・株価下落・売上低下・顧客への損害補償などで企業の経営自体が危うくなるケースもあります。

また、場合によってはAWS自体に被害を及ぼしたり、他のAWS利用者に迷惑を及ぼしたりする場合も想定され、被害者側から損害賠償請求を受ける可能性があります。

クラウド利用にはこうしたリスクがあることを踏まえて、利用者側もルールを守り、万全のセキュリティ対策を講じることが求められます。

責任共有モデルはAWS認定資格にも試験問題として出題されています。AWS認定の受験者の方は、その覚え方に苦慮されている方もいるかと思いますが、賃貸マンションのオーナーと入居者の関係で考えると覚えやすいでしょう。

建物全体の管理責任はオーナーにありますが、部屋の鍵を掛けるなど、各部屋のセキュリティは入居者の責任です。このように考えてみると、責任共有モデルにおける各々の責任範囲は非常に合理的だと分かります。

AWS側の責任範囲

責任共有モデルでは、AWS側の責任範囲はどこまでなのでしょうか？責任共有モデルにおけるAWS側の責任範囲は、AWSサービスのベースとなっているインフラストラクチャー部分です。これからAWSの責任範囲を1つずつ見ていきましょう。主な責任範囲を以下に列挙していきます。

AWSの施設（データセンター）は、リージョン > アベイラリビリティゾーン > データセンターの階層で世界中に展開されています。日本では2つのリージョン（東京と大阪）があり、リージョン間で相互バックアップが可能です。

さらに、データセンターは4つのレイヤー（施設・インフラストラクチャ・データ・環境）ごとに強固なセキュリティ対策が施されています。

また、データセンター自体が災害などによって機能停止に陥ると、他のAWSのデータセンターで機能を継続できるような仕組みが講じられています。これをディザスタリカバリ （disaster recovery） DR）と言います。こうしたデータセンター施設の管理責任は、すべてAWS側にあります。

AWSのリージョンとは？リージョン選択のおすすめポイントを解説

AWSのデータセンター内には、様々なインフラ設備があります。電源・空調・ネットワーク・サーバ・ストレージなどはすべて24時間の監視下にあり、冗長化などによって完全無停止を前提とした構成で稼働しています。このインフラストラクチャ全体の管理はAWSの責任範囲となっています。

AWSは、ホストOSに不正アクセスが行われないようなセキュリティを保障しています。これもAWSの責任範囲です。ホストOSに対するアクセスは多要素認証に基づく厳重な管理が行われ、外部からアクセスするのが非常に難しい仕様になっています。

またホストOSに対する操作が終了した後は、付与特権とアクセス権がその都度削除され、全てのアクセスのログが保管されています。

利用者側の責任範囲

AWSの責任共有モデルでは、AWSが提供するサービス以外はすべて利用者側の責任範囲です。利用するサービスによって責任範囲が異なるので、ここではAWSの代表的なIaaSサービスであるAmazon EC2を利用する場合の責任範囲について1つずつ見ていきましょう。

Amazon EC2 インスタンスなどAWSのIaaSを利用する場、「ゲストOSの更新やセキュリティパッチの適用、アプリケーションの管理、ファイアウォールの構成」などは利用者の責任範囲です。すなわち、ゲストOSよりも上のレイヤーに関してはすべて利用者責任ということです。

Amazon EC2 のサービスはIaaSのため、ネットワークの設定を含むセキュリティ構成や管理は利用者側の責任で行う必要があります。すなわち、ネットワークを介して情報漏洩などが起きれば、利用者側の責任となります。

ネットワークの設定に問題はないか、利用しないポートは開けっ放しになっていないかなど、十分なチェックが求められます。

Amazon EC2においては、利用者が持ち込んだアプリケーションは100%利用者側の責任で管理し、運用しなければなりません。アプリケーションの動作不具合などで、利用者側や、そのアプリケーションを利用する顧客が損害を負っても、AWS側には一切の責任がありません。

そのため、開発・導入したアプリケーションは十分なテスト、検証を行ってからリリースすることが求められます。

AWSサービスの中で取り扱うデータに関して、データの暗号化責任は利用者側にあります。取り扱うデータのオーナーはAWSサービスの利用者であり、その管理方法は利用者が決めることですので、AWSは一切関与できません。

データの暗号化の責任と同様、AWSサービスの利用者アカウント、アカウントに紐づくアプリやシステム、データへのアクセス権の管理や運用はすべて利用者の責任範囲です。アクセス権限管理漏れ、設定ミスがセキュリティ事故の多くを占めますので、利用者側は十二分に留意すべきでしょう。

ITエンジニアが知っておくべきAWSアカウントのセキュリティ管理

AWSを利用する上で行うべきセキュリティ対策

ここまで、AWS側と利用者側の責任範囲について確認をしましたが、それでは利用者側は具体的にどのようなセキュリティ対策を講じる必要があるのかを、見ていきましょう。ここでは、AWSを使用する際の代表的なセキュリティ対策をご紹介します。

【参考】：AWS アカウントのセキュリティを改善するための 10 個の項目｜AWS

利用に際して、まず初めにセキュリティグループの設定を行いましょう。セキュリティグループは仮想ファイアウォールとも呼ばれ、EC2インスタンスのセキュリティを確保する上で重要な役目があります。

セキュリティグループの設定では、EC2インスタンスに対してアクセス許可の範囲、トラフィックの制御を行うことができます。特に開発環境では関係者の出入りが多く、アクセス権限管理が難しくなり、セキュリティ被害を受けやすくなりがちです。

そのため、インバウンドルール（アクセス制限ルール）を厳しく設定して、必要がない人には公開しないようにすることが求められます。

【参考】：セキュリティグループを使用してリソースへのトラフィックを制御する｜AWS

セキュリティ対策としてログの管理は重要な要素の1つですので、定期的に認証情報を確認して、不審な認証がないかどうかを確認しましょう。

未使用のIDが不正アクセスに利用されるケースがありますので、発行済IDで一定期間利用がないIDは、本人の確認を得て削除します。不要なIDを無くすことが不正アクセス防止に重要です。

他には、ソフトウェアのバージョン管理も重要です。セキュリティの脆弱性が見つかると、それが攻撃の標的になりがちです。常にセキュリティパッチの有無を定期的に確認し、ソフトウェアのバージョン管理に細心の注意を払いましょう。

【参考】：CloudWatch でのログの検索および分析 - AWS の規範的ガイダンス ｜ AWS

AWSのサービスは全般的に強固なセキュリティ対策が施されていますが、クラウドはインターネットに対して公開された環境にあるため、ソフトウエアの脆弱性などを利用したマルウェアやコンピュータウィルスが侵入してくるリスクはゼロではありません。

また、自社のパソコンなどからウィルス感染する可能性もあります。マルアェア対策、ウィルス対策は利用者の責任ですので、アンチウィルスソフトを適用するなど、万全の対策を図ることが求められます。

AWSアカウントはデフォルトではメールアドレスとパスワードの組み合わせですが、これが盗まれると大変なことになります。そこで、AWSサービスの機能として備わっているMFA（多要素認証）を設定しておくとよいでしょう。これを有効にしておくと、第三者による不正ログインを防ぐことができます。

【参考】：AWS での多要素認証 (MFA) の使用 ｜ AWS

AWSは上記以外にアカウントセキュリティを高める方法として10項目の励行を提唱しています。他には、AWSの脆弱性診断サービス※がありますので、自社のセキュリティ脆弱性の診断を検討しましょう。

この第3者による診断によって、脆弱性の問題が客観的に分かりますので、効果的なセキュリティ対策を講じることができます。

【参考】：※アプリのセキュリティとコンプライアンスの改善をサポート ｜ AWS

クラウド利用の効果を最大化するために

ここまで、「AWSの責任共有モデル」について、概要、それぞれの責任範囲、セキュリティ対策などについて解説しました。

AWSという安全な環境を利用しても、セキュリティリスクが多く残ることに驚かれた方がいるかもしれませんが、セキュリティリスクの大半は人的リスクです。またAWSはオンプレミスと比較して、利用者側が行わなくてはならないセキュリティ対策は圧倒的に軽減されます。

だからこそ、政府や金融機関など、セキュリティ基準が厳しい組織がAWSを利用しているのです。責任共有モデルによって、AWSでは責任の分界点が明らかになっている点をポジティブに受け止め、AWSを正しく安全に利用して、クラウド利用の効果を最大化させていきましょう。

AWSの提供するマネージドサービスとは？メリットや利用方法を解説