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 Lambdaの責任共有モデル
AWSには「Lambda」というサーバレスのFaaS（Function as a Service）のサービスがあります。インスタンスを構築せず、いきなりコードを実行できるサービスですが、このLambdaにも責任共有モデルがあります。
Lambdaでの利用者側の主な責任範囲は、Lambda内にデプロイしたアプリケーションとデータ、そしてインターネットからのアクセスです。詳しくは「AWS Lambda のセキュリティの概要」に記されています。
【参考】：※AWS Lambda のセキュリティの概要-Security Overview of AWS Lambda_JP.pdf｜AWS
AWSの利用者によるセキュリティ事故
AWSをはじめとして、クラウドサービスは堅牢なセキュリティ対策を講じています。クラウド事業者側に起因する大規模な事故が起きれば、クラウドビジネスそのものが否定されかねないからです。
その結果、クラウドサービスにおけるセキユリティ事故の大半は、クラウド事業者側ではなく利用者側の人的なミスによって起きていると言われています。
主なものとしては、リモート操作で利用するSSH（Secure Shell）のポートの閉じ忘れによる不正ログイン、ストレージサービスのバケット開放による情報漏洩、IAM ユーザーやAWSアカウントルートユーザーのアクセスキー漏洩などが挙げられています。
個人情報の漏洩が起きると、その影響範囲は自社のみならず顧客全体に及び、その結果として企業の信用失墜・株価下落・売上低下・顧客への損害補償などで企業の経営自体が危うくなるケースもあります。
また、場合によってはAWS自体に被害を及ぼしたり、他のAWS利用者に迷惑を及ぼしたりする場合も想定され、被害者側から損害賠償請求を受ける可能性があります。
クラウド利用にはこうしたリスクがあることを踏まえて、利用者側もルールを守り、万全のセキュリティ対策を講じることが求められます。
責任共有モデルはAWS認定資格にも試験問題として出題されています。AWS認定の受験者の方は、その覚え方に苦慮されている方もいるかと思いますが、賃貸マンションのオーナーと入居者の関係で考えると覚えやすいでしょう。
建物全体の管理責任はオーナーにありますが、部屋の鍵を掛けるなど、各部屋のセキュリティは入居者の責任です。このように考えてみると、責任共有モデルにおける各々の責任範囲は非常に合理的だと分かります。
AWS側の責任範囲
責任共有モデルでは、AWS側の責任範囲はどこまでなのでしょうか？責任共有モデルにおけるAWS側の責任範囲は、AWSサービスのベースとなっているインフラストラクチャー部分です。これからAWSの責任範囲を1つずつ見ていきましょう。主な責任範囲を以下に列挙していきます。
1：物理的な保護
AWSの施設（データセンター）は、リージョン > アベイラリビリティゾーン > データセンターの階層で世界中に展開されています。日本では2つのリージョン（東京と大阪）があり、リージョン間で相互バックアップが可能です。
さらに、データセンターは4つのレイヤー（施設・インフラストラクチャ・データ・環境）ごとに強固なセキュリティ対策が施されています。
また、データセンター自体が災害などによって機能停止に陥ると、他のAWSのデータセンターで機能を継続できるような仕組みが講じられています。これをディザスタリカバリ （disaster recovery） DR）と言います。こうしたデータセンター施設の管理責任は、すべてAWS側にあります。
2：インフラストラクチャの管理
AWSのデータセンター内には、様々なインフラ設備があります。電源・空調・ネットワーク・サーバ・ストレージなどはすべて24時間の監視下にあり、冗長化などによって完全無停止を前提とした構成で稼働しています。このインフラストラクチャ全体の管理はAWSの責任範囲となっています。
3：ホストOS（ハイパーバイザー）の管理
AWSは、ホストOSに不正アクセスが行われないようなセキュリティを保障しています。これもAWSの責任範囲です。ホストOSに対するアクセスは多要素認証に基づく厳重な管理が行われ、外部からアクセスするのが非常に難しい仕様になっています。
またホストOSに対する操作が終了した後は、付与特権とアクセス権がその都度削除され、全てのアクセスのログが保管されています。
利用者側の責任範囲
AWSの責任共有モデルでは、AWSが提供するサービス以外はすべて利用者側の責任範囲です。利用するサービスによって責任範囲が異なるので、ここではAWSの代表的なIaaSサービスであるAmazon EC2を利用する場合の責任範囲について1つずつ見ていきましょう。
1：ゲストOS
Amazon EC2 インスタンスなどAWSのIaaSを利用する場、「ゲストOSの更新やセキュリティパッチの適用、アプリケーションの管理、ファイアウォールの構成」などは利用者の責任範囲です。すなわち、ゲストOSよりも上のレイヤーに関してはすべて利用者責任ということです。
2：ネットワーク設定
Amazon EC2 のサービスはIaaSのため、ネットワークの設定を含むセキュリティ構成や管理は利用者側の責任で行う必要があります。すなわち、ネットワークを介して情報漏洩などが起きれば、利用者側の責任となります。
ネットワークの設定に問題はないか、利用しないポートは開けっ放しになっていないかなど、十分なチェックが求められます。
3：アプリケーション
Amazon EC2においては、利用者が持ち込んだアプリケーションは100%利用者側の責任で管理し、運用しなければなりません。アプリケーションの動作不具合などで、利用者側や、そのアプリケーションを利用する顧客が損害を負っても、AWS側には一切の責任がありません。
そのため、開発・導入したアプリケーションは十分なテスト、検証を行ってからリリースすることが求められます。
4：データの暗号化
AWSサービスの中で取り扱うデータに関して、データの暗号化責任は利用者側にあります。取り扱うデータのオーナーはAWSサービスの利用者であり、その管理方法は利用者が決めることですので、AWSは一切関与できません。
5：アクセス権限管理
データの暗号化の責任と同様、AWSサービスの利用者アカウント、アカウントに紐づくアプリやシステム、データへのアクセス権の管理や運用はすべて利用者の責任範囲です。アクセス権限管理漏れ、設定ミスがセキュリティ事故の多くを占めますので、利用者側は十二分に留意すべきでしょう。
AWSを利用する上で行うべきセキュリティ対策
ここまで、AWS側と利用者側の責任範囲について確認をしましたが、それでは利用者側は具体的にどのようなセキュリティ対策を講じる必要があるのかを、見ていきましょう。ここでは、AWSを使用する際の代表的なセキュリティ対策をご紹介します。
【参考】：AWS アカウントのセキュリティを改善するための 10 個の項目｜AWS
セキュリティグループをしっかり設定する
利用に際して、まず初めにセキュリティグループの設定を行いましょう。セキュリティグループは仮想ファイアウォールとも呼ばれ、EC2インスタンスのセキュリティを確保する上で重要な役目があります。
セキュリティグループの設定では、EC2インスタンスに対してアクセス許可の範囲、トラフィックの制御を行うことができます。特に開発環境では関係者の出入りが多く、アクセス権限管理が難しくなり、セキュリティ被害を受けやすくなりがちです。
そのため、インバウンドルール（アクセス制限ルール）を厳しく設定して、必要がない人には公開しないようにすることが求められます。
【参考】：セキュリティグループを使用してリソースへのトラフィックを制御する｜AWS
認証情報を定期的に確認し、無効化する
セキュリティ対策としてログの管理は重要な要素の1つですので、定期的に認証情報を確認して、不審な認証がないかどうかを確認しましょう。
未使用のIDが不正アクセスに利用されるケースがありますので、発行済IDで一定期間利用がないIDは、本人の確認を得て削除します。不要なIDを無くすことが不正アクセス防止に重要です。
他には、ソフトウェアのバージョン管理も重要です。セキュリティの脆弱性が見つかると、それが攻撃の標的になりがちです。常にセキュリティパッチの有無を定期的に確認し、ソフトウェアのバージョン管理に細心の注意を払いましょう。
【参考】：CloudWatch でのログの検索および分析 - AWS の規範的ガイダンス ｜ AWS
マルウェア・ウィルス対策を施す
AWSのサービスは全般的に強固なセキュリティ対策が施されていますが、クラウドはインターネットに対して公開された環境にあるため、ソフトウエアの脆弱性などを利用したマルウェアやコンピュータウィルスが侵入してくるリスクはゼロではありません。
また、自社のパソコンなどからウィルス感染する可能性もあります。マルアェア対策、ウィルス対策は利用者の責任ですので、アンチウィルスソフトを適用するなど、万全の対策を図ることが求められます。
AWSのMFA（多要素認証）を利用する
AWSアカウントはデフォルトではメールアドレスとパスワードの組み合わせですが、これが盗まれると大変なことになります。そこで、AWSサービスの機能として備わっているMFA（多要素認証）を設定しておくとよいでしょう。これを有効にしておくと、第三者による不正ログインを防ぐことができます。
【参考】：AWS での多要素認証 (MFA) の使用 ｜ AWS
脆弱性診断サービスを使う
AWSは上記以外にアカウントセキュリティを高める方法として10項目の励行を提唱しています。他には、AWSの脆弱性診断サービス※がありますので、自社のセキュリティ脆弱性の診断を検討しましょう。
この第3者による診断によって、脆弱性の問題が客観的に分かりますので、効果的なセキュリティ対策を講じることができます。
【参考】：※アプリのセキュリティとコンプライアンスの改善をサポート ｜ AWS
クラウド利用の効果を最大化するために
ここまで、「AWSの責任共有モデル」について、概要、それぞれの責任範囲、セキュリティ対策などについて解説しました。
AWSという安全な環境を利用しても、セキュリティリスクが多く残ることに驚かれた方がいるかもしれませんが、セキュリティリスクの大半は人的リスクです。またAWSはオンプレミスと比較して、利用者側が行わなくてはならないセキュリティ対策は圧倒的に軽減されます。
だからこそ、政府や金融機関など、セキュリティ基準が厳しい組織がAWSを利用しているのです。責任共有モデルによって、AWSでは責任の分界点が明らかになっている点をポジティブに受け止め、AWSを正しく安全に利用して、クラウド利用の効果を最大化させていきましょう。
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから
