AWSの責任共有モデルは、NIST 800-53フレームワークに準拠

AWSの責任共有モデルについてまとめています。

1 AWSの責任共有モデルとは
2 AWSの責任共有モデルのまとめ

AWSの責任共有モデルとは

システム構築にAWSを利用する場合、システム障害やセキュリティインシデントの発生時の責任範囲を明確にしておく必要があります。

AWSを利用することで開発コストの圧縮や期間の短縮を図ることができるメリットがあり、ハードウェアなどインフラに近い部分はAWSの責任範囲となります。このため、システム開発をおこなうユーザにとっては責任範囲を減らすことができるのですが、「どこからどこまでが責任範囲か」を利用前に決めておかないと、障害発生時などにトラブルになってしまうんですね。

AWSの利用規約では、セキュリティの責任範囲について「責任共有モデル」という概念が示されています。ユーザのみが責任を負う部分、AWSのみが責任を負う部分、ユーザとAWSが責任を共有する部分が存在するとして、ユーザとAWSでセキュリティ保護の範囲と責任分界点を明確にしているんですね。AWSでは、以下の図を用いて説明がされています。

関連）責任共有モデル | AWS

AWSの責任範囲は、AWSクラウドで提供されるすべてのサービスを実行するインフラの保護です。インフラとは、具体的に何を差すのでしょう？

まず、AWSがサービス提供するためのハードウェアが設置されている施設です。台風や地震、洪水などの自然災害などの環境リスクから影響を受けにくい場所が選ばれていたり、地域全体で避けようのない災害が起こったときのために、物理的に離れた土地で処理を継続できるように冗長構成などを取ることを指します。

2つ目は、AWSサービスのインフラストラクチャです。サービスが稼働するサーバマシン、ネットワーク、電力システムなどのハードウェアやソフトウェアを指します。

3つ目は、ホストOSです。AWSのサービスは仮想マシン上で実行されているため、仮想環境を実現するために各サーバマシンではホストOSが稼働しているんですね。ホストOSへのアクセス権限を厳しく管理しセキュリティ対策を施すことで、外部からの不正アクセスを防いでいます。

ユーザの責任範囲は、AWSのサービス種類によって異なります。例えば、Amazon EC2では、ユーザはゲストOSの管理に責任を負います。

ゲストOSのバージョンアップやセキュリティパッチの適用も含まれます。ゲストOSよりも上位レイヤー（データベースなどのミドルウェアやアプリケーション）のインストールや設定、ファイアウォールの構成内容についても責任を負います。例えば、ゲストOSのセキュリティパッチ適用が遅れたために、ハッキングなど外部からのシステムへの侵入を許してしまった場合にはユーザの責任となるんですね。

Amazon EC2のようなIaaS（Infrastructure as a Service）タイプのサービスの場合、自由度が高いぶん、ユーザ側の責任範囲も大きくなるというわけです。

AWSとユーザが責任範囲を共有する部分は、ユーザがソフトウェアコンポーネントに設定したセキュリティ内容と、AWSが提供するインフラストラクチャのセキュリティです。

AWSは、NIST 800-53 フレームワークに準拠

AWSを利用したシステムが客観的に高度なセキュリティ保護をおこなっていることを示す方法があります。

AWSは、米国のセキュリティ統制NIST800-53フレームワークに準拠しています。NIST800-53は、アメリカ政府の情報システムに適用されるセキュリティ統制で、情報及び情報システムの機密性、完全性、可用性を十分に保護しているという評価・認証を行います。

AWS クラウドのインフラとサービスは、NIST 800-53 Revision 4 統制と追加のFedRAMP 要件について、第三者のテストで検証されています。AWS は、AWS GovCloud (アメリカ) 、 AWS 米国東部/西部リージョンで、複数の認証機関から FedRAMP Authorizations to Operate (ATO) を受けています。

あとは、ユーザ側の責任共有モデル、ユーザのみが責任を追う点についてNIST800-53フレームでの監査・認証をおこなうことでAWSを組み込んだシステムをNIST800-53準拠のシステムとして認証を取得することが可能です。

なお、NIST 800-53フレームワークは、アメリカ政府の情報システムにのみ適用されるものではありません。NIST800-53認証を取得することで、「アメリカ政府の情報システムなみに高度にセキュリティで保護されたシステムである」ということを示すことが可能です。

AWSは、アメリカ政府情報システム以外に、優良試験所基準 (GLP)、医薬品臨床試験の実施基準 (GCP)、適正製造基準 (GMP) などのいわゆるGxPと言われるコンプライアンス遵守が必要とされる要件でも実績があります。

AWSは、NIST 800-53以外にも、ISO 9001、ISO 27001、ISO 27017、ISO 27018 などのセキュリティと品質に関する他の認定も取得しています。

AWSのマネージドサービスの責任共有モデル

AWSのサービスの種類により、ユーザの責任範囲は変わります。例えば、Amazon RDSは、フルマネージド型のデータベースサービスです。

【関連記事】
▶AWSのデータベースサービス「Amazon RDS」とは？

ユーザが設定可能な、Amazon RDSの構成やデータベースのテーブル設計、格納するデータはユーザの責任範囲となります。AWSの責任範囲は、データベースサービスが稼働するオペレーティングシステムの管理やSQL ServerやMySQLなどのデータベースサービスのバージョンアップやセキュリティパッチの適用、高可用性のための冗長構成や障害発生時の切り替えなどとなります。責任共有部分は、ユーザのAmazon RDSの構成時の設定と、AWSが設定に基づいてセキュリティ保護を行う部分となります。

さらに、Amazon S3のようなサービスでは、ユーザがサービスの構成を細かくいじること自体できません。データ格納の上限は実質なしで、高可用性99.999999999%を実現するための冗長構成や障害発生時の切り替えの仕組みなども、「AWSにおまかせ」できるフルマネージド型サービスです。

【関連記事】
▶AWS S3ってどんなサービス？初心者向けに機能紹介

ユーザは、Amazon S3が稼働する環境のOS、ミドルウェア、アプリケーションがどのように動作するか一切理解する必要がなく、格納するデータと、データのアクセス権にのみ責任を持てば良いことになります。Amazon S3での責任共有部分は、ユーザのデータアクセス権限設定部分と、AWSがアクセス権限に基づいて適切なセキュリティを実施する箇所となります。

このように、フルマネージド型サービスを利用することで、設定の自由度が低くなる代わりに、ユーザ側の責任範囲や作業負荷を減らすことができます。

AWSの責任共有モデルのまとめ

ポテパンダの一言メモ

AWSの責任共有モデルとは、ユーザとAWSが責任を共有する箇所を明確にしたもの
AWSの責任共有モデルは、アメリカ政府の情報システムで採用されているNIST 800-53に準拠している
AWSの責任共有モデルでは、ユーザとAWSの責任範囲はAWSのサービスによって異なる
サービスの構成

エンジニアになりたい人に選ばれるプログラミングスクール「ポテパンキャンプ」

ポテパンキャンプは卒業生の多くがWebエンジニアとして活躍している実践型プログラミングスクールです。 1000名以上が受講しており、その多くが上場企業、ベンチャー企業のWebエンジニアとして活躍しています。

基礎的な学習だけで満足せず、実際にプログラミングを覚えて実践で使えるレベルまで学習したいという方に人気です。プログラミングを学習し実践で使うには様々な要素が必要です。

それがマルっと詰まっているポテパンキャンプでプログラミングを学習してみませんか？

卒業生の多くがWebエンジニアとして活躍

卒業生の多くがWeb企業で活躍しております。
実践的なカリキュラムをこなしているからこそ現場でも戦力となっております。
活躍する卒業生のインタビューもございますので是非御覧ください。

経験豊富なエンジニア陣が直接指導

実践的なカリキュラムと経験豊富なエンジニアが直接指導にあたります。
有名企業のエンジニアも多数在籍し品質高いWebアプリケーションを作れるようサポートします。

満足度高くコスパの高いプログラミングスクール「ポテパンキャンプ」

運営する株式会社ポテパンは10,000人以上のエンジニアのキャリアサポートを行ってきております。
そのノウハウを活かして実践的なカリキュラムを随時アップデートしております。

代表の宮崎もプログラミングを覚えサイトを作りポテパンを創業しました。
本気でプログラミングを身につけたいという方にコスパ良く受講していただきたいと思っておりますので、気になる方はぜひスクール詳細をのぞいてくださいませ。

AWSの責任共有モデルは、NIST 800-53フレームワークに準拠