AWS運用の責任共有モデルとは
AWSをはじめとしたIaaSを提供するクラウド事業者は、情報セキュリティやコンプライアンスに関して一般的に「責任共有モデル」という考え方を採用しています。これは、クラウド事業者と利用者(お客様)で責任範囲を明確にして、全体のセキュリティを担保しようという考え方です。
多くの場合、クラウドは従来のオンプレミスと比べてセキュリティ対策範囲が小さくなるので、利用者(お客様)のセキュリティに関する負担が軽くなりますが、利用者(お客様)自身の責任範囲についてはしっかりと対策する必要があります。
安心して利用するために、IaaS型クラウドにおけるシェアトップのAWSを例に「責任共有モデル」について改めて見ていきましょう。
目次
AWS運用のセキュリティの基本的な考え方「責任共有モデル」
AWSの責任共有モデルを説明する図としてよく使われるのが以下の図です。
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
下半分のオレンジ色の範囲がAWSが責任を負う「クラウド “の” セキュリティ」です。
インフラ部分(ホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素)をAWSが運用、管理します。
そして、上半分がお客様(私たち利用者)が責任を負う「クラウド “における” セキュリティ」です。
仮想ネットワークやOS内部(ゲストオペレーティングシステム)、関連アプリケーションソフトウェア、AWSが提供するサービスの各種設定について運用、管理します。
AWSはこの責任共有モデルの性質によって、利用するサービスや使い方に合わせて運用、管理ができる柔軟性と、セキュリティとコンプライアンスを維持するための運用上の負担軽減を両立してます。
AWSの責任範囲
AWSの責任範囲である「クラウド “の” セキュリティ」は、物理的なインフラや仮想環境を動かすハイパーバイザー(ホストOS)の保護になります。AWSのWebサイトには次のように記載されています。
AWS の “クラウドのセキュリティ” 責任 – AWS は、AWS クラウドで提供されるすべてのサービスを実行するインフラストラクチャの保護について責任を負います。このインフラストラクチャはハードウェア、ソフトウェア、ネットワーキング、AWS クラウドのサービスを実行する施設で構成されます。
責任共有モデル | AWS
では実際、AWSが責任を負うインフラ部分はどのように保護されているのでしょうか?
簡単にまとめてみました。
自然災害からの保護
AWSのデータセンターは、洪水、異常気象、地震活動などの環境リスクを軽減するために慎重に選択された場所にあります。また、リージョンを構成するアベイラビリティーゾーン(AZ)間は物理的に分離されており、それぞれ独立して構築されています。これにより、自然災害や地震で一方のAZが影響を受けた時に、自動的に処理中のトラフィックを影響のある地域から移動できるようになります。
物理的なアクセス
非公開となっているAWSのデータセンターは、物理的な位置によって、保安要員、防御壁、侵入検知テクノロジー、監視カメラ、二要素認証など様々なセキュリティで保護されています。AWSの関係者であっても物理的なアクセスが許可されているのは権限を持つ担当者だけで、第三者のアクセスは、承認されたAWSの担当者が申請しなくてはなりません。
どちらの場合もデータセンターに入るためには、まずアクセスを申請し、業務上の正当性を詳しく説明する必要があります。また、許可されて入場したあとも期限とエリアは制限され、すべてのアクセスは記録、監査対象となります。
インフラストラクチャー
データセンターの電力システムは完全に冗長化され24時間年中無休で稼動しており、電力障害時に施設内の重要かつ不可欠な業務に対応するためのバックアップ電源を備えています。
空調はハードウェアの適切な運用温度を保つためのメカニズムを使用し、作業員とシステムが、温度と湿度を適切なレベルになるよう監視してコントロールしています。
ハイパーバイザー(ホストOS)
承認を受けたAWS管理者の拠点ホストからの個別のログインとなっており、多要素認証が利用されます。特別に設計、構築、設定された管理ホストが使用され、作業完了後はシステムへの特権とアクセス権が削除されます。 全てのアクセスはロギングされ、監査対象になります。
パンデミックへの対応
パンデミック対応ポリシーと手順を災害復旧計画に組み込んで、爆発的に流行する感染症の脅威に迅速に対応するための準備をしています。
これらの取り組みが十分に機能しているかは、ISO 27001(情報セキュリティ)、ISO 27017(クラウドサービスセキュリティ)、SOC2 など、AWSが取得している数々の第三者認証で確認することができます。
AWS運用における利用者(お客様)の責任範囲
私たち利用者の責任範囲である「クラウド “における” セキュリティ」は、OSやミドルウェア、ネットワーク設定、アプリケーション、データの暗号化、アクセス権限の管理など、基本的にOSから上のレイヤーになります。
そのため、構築時にはこれらのセキュリティについてしっかりと考慮する必要があり、構築後もセキュリティアップデート等の保守が欠かせません。
AWSのWebサイトには次のように記載されています。
お客様の “クラウドにおけるセキュリティ” 責任 – お客様の責任は、選択した AWS クラウドのサービスに応じて異なります。選択によって、セキュリティに関する責任の一環としてお客様が実行する構成作業の量が決定されます。たとえば、Amazon Elastic Compute Cloud (Amazon EC2) などのサービスは Infrastructure as a Service (IaaS) に分類されているため、必要なすべてのセキュリティ構成および管理のタスクをお客様が実行する必要があります。お客様が Amazon EC2 インスタンスをデプロイした場合、お客様は、ゲストオペレーティングシステムの管理 (更新やセキュリティパッチなど)、インスタンスにインストールしたアプリケーションソフトウェアまたはユーティリティの管理、AWS より各インスタンスに提供されるファイアウォール (セキュリティグループと呼ばれる) の構成に責任を負います。 Amazon S3 や Amazon DynamoDB などの抽象化されたサービスの場合、AWS はインフラストラクチャレイヤー、オペレーティングシステム、およびプラットフォームを運用し、お客様はエンドポイントにアクセスしてデータを保存および取得します。お客様は、データの管理 (暗号化オプションを含む)、アセットの分類、IAM ツールでの適切な権限の適用について責任を負います。
責任共有モデル | AWS
マネージドサービスを活用して運用負荷を軽減
AWSは利用するサービスによっても責任範囲が変わってきます。
IaaS (Infrastructure as a Service) に分類される Amazon EC2 にサービスを構築する場合と、Amazon RDS などのマネージドサービスや AWS Lambda などのサーバレスのサービスを活用してサービスを構築した場合では、パッチの適用やバックアップ管理等、セキュリティに関連する負荷は大きく異なります。
マネージドサービスはOSやミドルウェアもAWSが管理してくれるので、利用者の責任の範囲が通常より狭くなります。
積極的にマネージドサービスを利用することで、運用負荷を軽減することができます。
設定ミスはユーザーの責任 ── 誰も助けてくれないの?
責任共有モデルの「お客様の責任範囲」であっても、AWSは何もしないわけではなく、セキュリティを確保するための様々な機能やサービスを用意しています。
例えば Amazon EC2 などのサービスで利用できる「セキュリティグループ」というアクセス制御の機能はAWS側で接続元のIPとポート番号を制限できます。
他にも、ユーザー側でカスタマイズ可能なWAF(Webアプリケーションファイアウオール)の「AWS WAF」や、ユーザー側の設定が不要なDDoS(分散型サービス拒否攻撃)対策サービス「AWS Shield」といったサービスが提供されています。
ただ結局のところ、あくまでAWSは提供しているだけなので、設定や管理は利用者である私たちユーザーの責任範囲です。もし仮にAWSの設定を間違えたまま利用してセキュリティインシデントが発生したとしても「すべてはユーザーの責任」となります。
「そんな、ユーザーの責任って言われても、クラウドの設定や構築は勝手もわからないし、不安、、どうすりゃいいの!?」
…とお嘆きのそこのあなた! ご安心ください。
そんな時のために、我々AWSのパートナーがいるんです。
いつでもお気軽にご相談ください。
AWS運用の責任共有モデル まとめ
いかがでしたでしょうか?
クラウドは良くも悪くもセルフサービスです。
そこで、クラウド事業者が関与しない範囲をいかに守るかが重要なポイントとなります。
ただ、そうは言っても実際には、
「意図したとおりに設定できているか」
「最も良い方法(ベストプラクティス)はどういったものなのか」
クラウド導入時はもちろん、使ったことがない新しいサービスを初めて利用するときには不安がつきものです。
お困りの際は、APNアドバンスドコンサルティングパートナーの弊社、ターン・アンド・フロンティアまで、お気軽にご相談ください。
元記事発行日: 2021年03月04日、最終更新日: 2024年02月28日