fbpx

NCSC UKのクラウドセキュリティ原則のコンテキストでAWSを使用する

好きな所から読む

この記事は、英国(UK)のアマゾンウェブサービス(AWS)を使用している組織を支援することを目的としています。クラウドセキュリティガイダンスの下で公開されている国立サイバーセキュリティセンター(NCSC)のクラウドセキュリティ原則に沿って公式に分類されたワークロード。このドキュメントは、読者が次のことを理解できるようにすることを目的としています。

  • AWSがどのようにセキュリティプロセスを実装し、クラウドセキュリティ原則ごとにそれらのプロセスを保証するか
  • AWSに保存されているコンテンツの管理と保護において、お客様とAWSが果たす役割
  • AWSクラウドサービスを使用してセキュリティとリスク管理に対応する方法など、AWSサービスの動作方法

範囲

この記事は、NCSCクラウドセキュリティ原則に関連してOFFICIAL情報を処理することの影響を検討する際にAWSのお客様が尋ねる一般的な質問に基づいています。私たちの目的は、一般的なセキュリティ要件への対処に役立つリスク評価を実行するときに、情報に基づいた決定を行うために使用できるガイダンスを提供することです。このホワイトペーパーは、AWSの特定の使用に関する法的助言ではありません。特定のデータのプライバシーとセキュリティの要件、およびプロジェクトとデータセットに関連する適用法について、適切なコンプライアンスアドバイスを取得することを強くお勧めします。

公的機関に対する考慮事項

NCSCは、2014年4月23日に公式情報を処理するためのクラウドサービスの使用を検討している公的機関向けのクラウドセキュリティガイダンスドキュメントを公開しました。このガイダンスの下で、HM政府情報資産は現在、公式、秘密、およびトップシークレットの3つのカテゴリに分類されています。各情報資産の分類は、典型的な脅威に対する適切な保護を提供するセキュリティ制御のベースラインセットを引き付けます。

NCSCクラウドセキュリティガイダンスには、クラウドサービスを使用するためのリスク管理アプローチ、クラウドセキュリティ原則の概要、およびクラウドセキュリティ原則の実装に関するガイダンスが含まれています。さらに、サポートされているガイダンスドキュメントには、認識されている標準と定義、クラウドサービスの分離要件、およびサービスとしてのインフラストラクチャ(IaaS)サービスのお客様が実施を検討する必要のある措置に関する具体的なガイダンスが含まれています。

この記事は、AWSがクラウドセキュリティの原則とどのように連携するか、およびNCSCのクラウドセキュリティガイダンスの一部としてこれらの原則の目的についてのガイダンスを提供します。レガシーインパクトレベル認定スキームは段階的に廃止され、クラウドサービスを含むシステムのセキュリティプロパティを記述するために使用されるメカニズムではなくなりました。公共部門の組織は、クラウドサービスの使用に関するリスク管理の決定に最終的に責任を負います。

Gov.UKデジタルマーケットプレイス

AmazonWeb Servicesは現在、英国政府デジタルマーケットプレイスの英国G-Cloudページに記載されているサービスを提供しています。

AWSサービスを使用する場合、お客様はコンテンツを完全に制御し、以下を含む重要なコンテンツセキュリティ要件を管理する責任があります。

  • AWSに保存することを選択したコンテンツ
  • コンテンツで使用されるAWSサービス
  • コンテンツが保存されている国
  • そのコンテンツのフォーマットと構造、およびマスクされているか、匿名化されているか、暗号化されているか
  • そのコンテンツに誰がアクセスでき、それらのアクセス権がどのように付与、管理、および取り消されるか

AWSのお客様はデータの制御を保持しているため、AWSの「共有責任」モデルの一部として、そのコンテンツに関連する責任も保持しています。この共有責任モデルは、クラウドセキュリティ原則に照らして顧客とAWSのそれぞれの役割を理解するための基本です。

責任分担環境

AWSを使用すると、顧客とAWSの間で共有責任モデルが作成されます。AWSは、ホストオペレーティングシステムと仮想化レイヤーから、サービスが動作する施設の物理的なセキュリティに至るまで、コンポーネントを操作、管理、制御します。次に、ゲストは、ゲストオペレーティングシステム(更新プログラムやセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの構成を担当し、管理します。責任は使用するサービス、それらのサービスのIT環境への統合、適用される法律や規制によって異なるため、顧客は選択するサービスを慎重に検討する必要があります。ホストベースのファイアウォール、ホストベースの侵入検知/防止、暗号化などのテクノロジーを活用することで、セキュリティを強化したり、より厳しいコンプライアンス要件を満たすことができます。AWSは、拡張されたIT環境でコントロールが効果的に機能していることを説明し、検証するためのお客様の支援に役立つツールと情報を提供します。

AWSでのクラウドセキュリティ原則の実装

NCSCによって発行されたクラウドセキュリティガイダンスは、クラウドサービスを評価するときに考慮すべき14の重要な原則と、これらが公共部門組織にとってなぜ重要であるのかを示しています。クラウドサービスのユーザーは、どの原則が重要であり、これらの原則の実装にユーザーが必要とする保証(ある場合)の程度を決定する必要があります。

14のクラウドセキュリティ原則、その目的、およびAWSサービスを使用してこれらの目的を実装する方法を、関連する保証アプローチとともに説明します。

原則1:転送中のデータの保護

実装アプローチ

AWSはさまざまなテクノロジーを使用して、コンシューマーとサービスの間、各サービス内、およびサービス間のデータ転送保護を可能にします。クラウドインフラストラクチャとアプリケーションは、インターネットなどのパブリックリンクを介して通信することが多いため、クラウドでアプリケーションを実行するときは、転送中のデータを保護することが重要です。これには、クライアントとサーバー間のネットワークトラフィック、およびサーバー間のネットワークトラフィックの保護が含まれます。データ保護のためにネットワークセキュリティを有効にする方法の詳細については、次のセクションで説明します。

AWSネットワーク保護

AWSネットワークは、ネットワーク攻撃に対する保護を提供します。データへの不正な内部および外部アクセスを適切に制限するための手順とメカニズムが整備されており、顧客データへのアクセスは他の顧客から適切に分離されています。

例は次のとおりです。

分散型サービス拒否(DDoS)攻撃:AWS APIエンドポイントは、大規模なインターネット規模のインフラストラクチャでホストされ、独自のDDoS軽減技術を使用します。 さらに、AWSネットワークは、インターネットアクセスの多様性を実現するために、複数のプロバイダーにわたってマルチホーム化されています。

Man in the Middle(MITM)攻撃:すべてのAWS APIは、サーバー認証を提供するSecure Sockets Layer(SSL)で保護されたエンドポイントを介して利用できます。Amazon EC2 Amazonマシンイメージ(AMI)は、最初の起動時に新しいセキュアシェル(SSH)ホストキーを自動的に生成し、インスタンスのコンソールに記録します。その後、お客様はセキュアAPIを使用してコンソールを呼び出し、ホストキーにアクセスしてから、インスタンスに初めてログインできます。お客様は、AWSとのすべてのやり取りにSSLを使用できます。

インターネットプロトコル(IP)スプーフィング:AWSが制御するホストベースのファイアウォールインフラストラクチャでは、インスタンスが独自のソースIPアドレスまたはメディアアクセスコントロール(MAC)アドレスを使用してトラフィックを送信することはできません。

ポートスキャン:Amazon EC2のお客様による許可されていないポートスキャンは、AWSの利用規定に違反しています。AWSの利用規定の違反は真剣に受け止められ、報告された違反はすべて調査されます。お客様は、弊社のWebサイト(http://aws-portal.amazon.com/gp/aws/html-forms- controller / contactus / AWSAbuse)で入手可能な連絡先を介して、不正行為の疑いを報告できます。不正なポートスキャンがAWSによって検出されると、停止され、ブロックされます。デフォルトでは、Amazon EC2インスタンスのすべての受信ポートは閉じられており、お客様のみが開くため、Amazon EC2インスタンスのポートスキャンは一般に効果がありません。お客様がセキュリティグループを厳密に管理することで、ポートスキャンの脅威をさらに軽減できます。顧客は、クラウドインフラストラクチャの行動スキャンに許可を要求することができます限り、彼らは顧客のインスタンスに制限されており、AWSに利用規定に違反していません。これらのタイプのスキャンの事前承認は、AWSの脆弱性/侵入テストリクエストフォームからリクエストを送信することで開始できます。

顧客ネットワーク保護

仮想プライベートクラウド(VPC):VPCはAWSクラウドの分離された部分であり、その中で顧客はVECのIPアドレス範囲をセグメント化するサブネットにAmazon EC2インスタンスをデプロイし(顧客が指定したとおり)、あるサブネットのAmazon EC2インスタンスを別のサブネットに分離できます。VPC内のAmazon EC2インスタンスには、VPCに対して確立されたIPsec仮想プライベートネットワーク(VPN)接続を介してのみ顧客がアクセスできます。

IPsec VPN:IPsec VPN接続は、お客様のVPCをお客様が指定した別のネットワークに接続します。IPsecは、データストリームの各IPパケットを認証および暗号化することにより、IP通信を保護するためのプロトコルスイートです。Amazon VPCのお客様は、事前共有キーを認証として使用して、Amazon VPC、VPNゲートウェイ、および別のネットワークゲートウェイ間にインターネットキーエクスチェンジ(IKE)セキュリティアソシエーションを最初に確立することにより、VPCへのIPsec VPN接続を作成できます。IKEは確立時に、一時鍵をネゴシエートして、将来のIKEメッセージを保護します。SHA-1認証やAES 128ビット暗号化など、パラメータ間で完全な合意がない限り、IKEセキュリティアソシエーションは確立できません。次に、IKE一時キーを使用して、VPNゲートウェイとカスタマーゲートウェイの間にキーが確立され、IPsecセキュリティと関連付けが形成されます。ゲートウェイ間のトラフィックは、このセキュリティアソシエーションを使用して暗号化および復号化されます。IKEは、IPsecセキュリティアソシエーション内のトラフィックの暗号化に使用される一時キーを定期的に自動的にローテーションして、通信の機密性を確保します。

API:Amazon VPC API呼び出しは、Amazon EC2WSDLの一部です。VPC、サブネット、VPNゲートウェイ、およびIPsec VPN接続を作成および削除するためのすべてのAPI呼び出しは、X.509証明書と関連するプライベートキーまたはお客様のAWSシークレットアクセスキーを使用してすべて署名されます。顧客のシークレットアクセスキーまたはX.509証明書にアクセスできない場合、Amazon EC2 API呼び出しはその顧客のキーペアで正常に行うことができません。さらに、API呼び出しをSSLで暗号化して機密性を維持できます。

AWS暗号化(転送中のデータ)

AWSは、転送中のデータを保護するためにIPsecとSSL/TLSの両方をサポートしています。IPsecは、多くの場合ネットワークインフラストラクチャでIPプロトコルスタックを拡張するプロトコルであり、上位層のアプリケーションが変更なしで安全に通信できるようにします。一方、SSL / TLSはセッションレイヤーで動作し、サードパーティのSSL / TLSラッパーがありますが、多くの場合、アプリケーションレイヤーでのサポートも必要です。輸送中のセキュリティにおけるAWSサービス固有のデータの詳細については、AWSセキュリティのベストプラクティスホワイトペーパーを参照してください。

保証アプローチ

AWSサービス内の輸送保護原則および関連プロセスのデータは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認証は、とりわけ、クラウド認証スキームに基づいて、EUのネットワークおよび情報セキュリティ機関(ENISA)によって承認されています。輸送中のデータ保護に関する管理は、少なくとも毎年、認定プログラムの下で個別に検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

原則2:資産の保護と回復力

実装アプローチ

AWSクラウドは、グローバルに利用可能なプラットフォームであり、データが配置されている地理的領域を選択できます。AWSデータセンターは、さまざまなグローバルリージョンのクラスターに構築されています。AWSは、これらのデータセンタークラスターをアベイラビリティーゾーン(AZ)と呼んでいます。2016年10月の時点で、AWSは38のAZをグローバルに14のリージョンに編成しています。AWSの顧客、あなたは慎重にあなたのシステムが常駐するアベイラビリティゾーンを選択するための責任を負います。AWSマネジメントコンソール内で利用可能な組み込み機能を使用して、1つのリージョン、すべてのリージョン、またはリージョンの任意の組み合わせを選択できます。

AWSリージョンとアベイラビリティーゾーンにより、ロケーション固有の要件またはリージョンのデータプライバシーポリシーがある場合、プライベートAWS環境を適切なロケーションに確立して維持できます。複数のリージョンでコンテンツを複製およびバックアップすることを選択できます。AWSは、お客様が設定したリージョンの外に顧客データを移動しません。

アベイラビリティーゾーンは、障害分離のために設計されています。それらは複数のインターネットサービスプロバイダー(ISP)と異なる電力網に接続されています。それらは高速リンクを使用して相互接続されているため、アプリケーションは同じ地域内のアベイラビリティーゾーン間の通信をローカルエリアネットワーク(LAN)接続に依存できます。

2015年3月6日、モデル条項を含むAWSデータ処理の補遺が、第29条作業部会として知られるEUデータ保護当局のグループによって承認されました。この承認は、モデル条項を必要とするすべてのAWSのお客様が、指令に従って国際的なデータフローを可能にするために十分な契約上のコミットメントを提供するAWSのデータ処理補遺を信頼できることを意味します。第29条作業部会の承認の詳細については、ルクセンブルクデータ保護機関のWebページにアクセスしてください。

AWSは、個人データの処理およびそのようなデータの自由な移動に関する個人の保護について、1995年10月24日の欧州議会および理事会の指令95/46 / ECに準拠しています。

ほとんどの国には、域外適用を目的とするデータアクセス法があります。クラウドサービスのコンテキストでよく言及される、領域外に到達する米国の法律の例は、米国の愛国者法です。愛国者法は、政府が国際テロやその他の外国情報問題に関連する調査に関する情報を入手できるようにする他の多くの先進国の法律と似ています。愛国者法に基づく文書の要求には、その要求が法律に準拠していることを示す裁判所命令が必要です。これには、要求が正当な調査に関連していることなどが含まれます。

保証アプローチ

AWSサービス内の法的管轄区域の原則と関連プロセスは、ISO 27001:2013およびAICPA SOC 1、SOC 2、SOC 3認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認証は、クラウド認証スキームに基づいて、EUのネットワークおよび情報セキュリティ機関(ENISA)によって承認されています。法的管轄権に関連する統制は、認証プログラムに基づいて、少なくとも年1回独立して検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

物理的な場所の原則と関連するプロセスは、AWSコンプライアンスプログラム内で個別に検証されません。Cloud Security Principlesガイダンスで選択できるように提供された代替案に基づくと、物理的な場所に関する制御は、それらを個別に検証するための既存の認定プログラム内には存在しません。当社のISO 27001:2013およびISO 9001:2008認定は、独立した年次監査の対象となるすべての場所をリストしています。AWSは、リージョン固有の要件に関してサービスプロバイダーアサーションを使用します。

2.2データセンターのセキュリティ

実装アプローチ

Amazonは、大規模なデータセンターのセキュリティ保護、設計、構築、運用において豊富な経験を持っています。この経験はAWSプラットフォームとインフラストラクチャに適用されています。

AWSは、そのような特権について正当なビジネスニーズを持つ承認された従業員および請負業者にデータセンターの物理的アクセスを提供します。すべての個人は身分証明書を提示する必要があり、サインインします。訪問者は、許可されたスタッフに付き添われます。

従業員または請負業者がこれらの特権を必要としなくなった場合、たとえ彼または彼女が引き続きAmazonまたはAWSの従業員であったとしても、そのアクセス権は即座に取り消されます。さらに、AmazonのHRシステムで従業員のレコードが終了すると、アクセスは自動的に取り消されます。

カード所有者によるデータセンターへのアクセスは、四半期ごとに見直されます。削除のマークが付けられたカード所有者は、四半期レビューの一環としてアクセスを取り消されます。

物理的なアクセスは、ビデオ監視、侵入検知システム、その他の電子的手段を利用する専門のセキュリティスタッフによって、境界と建物の入口の両方で制御されます。承認されたスタッフは、多要素認証メカニズムを利用してデータセンターのフロアにアクセスします。

保証アプローチ

AWSサービス内のデータセンターのセキュリティの原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。データセンターのセキュリティに関する管理は、少なくとも毎年、認定プログラムに基づいて個別に検証されます。

2.3保存データの保護

実装アプローチ

AWSのお客様は、さまざまなセキュリティおよびデータ保護機能にアクセスして、保管中のデータが不正アクセスから保護されていることを十分に確信できます。ストレージメディアの保存データを保護するために広く使用されている方法の1つは暗号化です。AWSには、完全に自動化されたAWS暗号化ソリューション(サーバー側)から手動のクライアント側オプションまで、データを暗号化するためのいくつかのオプションがあります。特定の暗号化モデルを使用するかどうかの決定は、使用されているAWSサービス、組織のポリシー、規制およびビジネスコンプライアンス要件、技術的能力、データ使用証明書の特定の要件、その他の要因など、さまざまな要因に基づく場合があります。ユーザーまたはAWSが暗号化方法を提供し、キー管理インフラストラクチャ(KMI)を操作する方法には、3つの異なるモデルがあります。

多くのAWSサービスに組み込まれているクライアント側およびサーバー側の暗号化機能に加えて、KMIでキーを保護する別の一般的な方法は、デバイス上のキーを使用して暗号化操作を実行する専用のストレージおよびデータ処理デバイスを使用することです。これらのデバイスは、ハードウェアセキュリティモジュール(HSM)と呼ばれ、不正使用の証拠からキーを保護するための改ざんの証拠または抵抗を提供します。制御されたデータセットにAWS暗号化機能を使用することを選択したお客様の場合、AWS CloudHSM サービスはAWS環境内のもう1つの暗号化オプションであり、安全なキーの管理のために米国政府規格(NIST FIPS 140-2)に設計および検証されたHSMを使用できます。

AWSサービスでデータの暗号化を制御するキーを管理したいが、AWSの内部または外部で必要なKMIリソースを管理したくない場合は、AWS Key Management Service(KMS)を利用できます。AWS Key Management Serviceは、データの暗号化に使用される暗号化キーを簡単に作成および制御できるマネージドサービスであり、HSMを使用してキーのセキュリティを保護します。AWS Key Management Serviceは他のAWSサービスと統合されており、規制やコンプライアンスのニーズを満たすのに役立ちます。AWS KMSおよびDigital Marketplaceに記載されていないその他のAWSサービスは、パートナーネットワークを通じてご利用いただけます。AWS KMSでは、キーの作成、ローテーション、および使用ポリシーを実装することもできます。AWS KMSは、マスターキーへのアクセスが制限されるように設計されています。このサービスは、プレーンテキストのマスターキーをディスクに保存しない、メモリに保持しない、デバイスに接続できるシステムを制限するなどの広範な強化技術でマスターキーを保護するように設計されたシステムに基づいて構築されています。サービス上の更新ソフトウェアへのすべてのアクセスは、Amazon内の独立したグループによって監査およびレビューされるマルチレベルの承認プロセスによって制御されます。

AWS環境内の暗号化オプションの詳細については、「暗号化による保管時のデータの保護」およびAWS CloudHSM 製品の詳細ページを参照してください。AWS KMSの仕組みの詳細については、AWS Key Management Serviceの記事をご覧ください。

Amazon S3、Amazon EBS、Amazon RDS、Amazon Glacierの特定の保存データ保護機能の詳細については、AWSセキュリティベストプラクティスホワイトペーパーを参照してください。

保存中のデータを保護するための物理的なセキュリティ管理への実装アプローチについては、このドキュメントのデータセンターのセキュリティ(セクション2.2)に記載されている詳細を参照してください。

保証アプローチ

AWSサービス内の保存データ保護の原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。保存データ保護に関連する管理は、少なくとも毎年、認定プログラムの下で個別に検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

2.4データの無害化

実装アプローチ

お客様のシステムとデータの機密性、整合性、可用性を保護することは、お客様の信頼と信頼を維持することと同様に、AWSにとって最も重要です。AWSは業界が認めた標準で説明されている手法を使用して、リソースが移動または再プロビジョニングされたとき、リソースがサービスを終了したとき、またはデータの消去を要求したときに、データを確実に消去します。

AWSデータ消去

アマゾンEBSボリュームはのために前に利用可能になるまで拭いてきた生の未フォーマットのブロックデバイスとしてあなたに提示されているuse.Wiping 再プロビジョニングする前に必須のプロセスとして再利用する直前に発生します。DoD 5220.22-M(「National Industrial Security Program Operating Manual」)またはNIST 800-88(「Media Sanitizationのガイドライン」)に詳述されているような特定の方法ですべてのデータをワイプする必要がある手順がある場合、 Amazon EBSでこれを行う機能。確立された要件に準拠するために、ボリュームを削除する前に特別なワイプ手順を実行する必要があります。

同様に、Amazon RDSデータベースインスタンスの削除がリクエストされると、データベースインスタンスは削除対象としてマークされます。Amazon RDSオートメーションスイーパーは、Amazon RDSストレージシステムからインスタンスを削除します。この時点で、お客様またはAWS はインスタンスにアクセスできなくなり、お客様が「最終スナップショットコピーを使用した削除」を要求しない限り、インスタンスは復元できず、ツールやAPIのいずれにもリストされません。

AWSの安全な破壊

ストレージデバイスが耐用年数の終わりに達したとき、AWSの手順には、顧客データが許可されていない個人に公開されるのを防ぐように設計された廃止プロセスが含まれています。AWSは、DoD 5220.22-M(「National Industrial Security Program Operating Manual」)またはNIST 800-88(「Media Sanitizationのガイドライン」)に詳述されている手法を使用して、廃止プロセスの一部としてデータを破棄します。廃止されたすべての磁気ストレージデバイスは、業界標準の慣例に従って消磁され、物理的に破壊されます。

保証アプローチ

AWSサービス内のデータサニタイゼーションのサブ原理と関連プロセスは、ISO 27001:2013およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査を受ける必要があります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。データのサニタイゼーションに関連する制御は、少なくとも毎年、認定プログラムの下で個別に検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

2.5機器の廃棄

実装アプローチ

お客様のシステムとデータの機密性、整合性、可用性を保護することは、お客様の信頼と信頼を維持することと同様に、AWSにとって最も重要です。AWSは業界で認められた標準で説明されている手法を使用して、リソースが移動または再プロビジョニングされたとき、サービスを終了したとき、または消去を要求したときに、データが確実に消去されるようにします。

ストレージデバイスが耐用年数の終わりに達したとき、AWSの手順には、顧客データが権限のない個人に公開されるのを防ぐように設計された廃止プロセスが含まれています。AWSは、DoD 5220.22-M(「National Industrial Security Program Operating Manual」)またはNIST 800-88(「Media Sanitizationのガイドライン」)に詳述されている手法を使用して、廃止プロセスの一部としてデータを破棄します。廃止されたすべての磁気ストレージデバイスは、業界標準の慣行に従って消磁され、物理的に破壊されます。

保証アプローチ

AWSサービス内の機器保護の原則と関連プロセスは、ISO 27001:2013およびPCI-DSS認証プログラムに基づいて、少なくとも毎年監査の対象となります。 これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。機器の保護に関連する制御は、認証プログラムに基づいて、少なくとも毎年毎年独立して検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

2.6物理的な復元力と可用性

実装アプローチ

AWSレジリエンシープログラムは、AWSが環境内の主要なイベントまたはインシデントを特定、対応、および復旧するプロセスと手順を網羅しています。このプログラムは、停止からの回復機能を含む、サービスの可用性コミットメントに対するビジネスニーズが満たされているという十分な信頼を提供することを目的としています。このプログラムは、ビジネス継続性と災害復旧計画の要素を組み込んだ緊急時対応に取り組む従来のアプローチに基づいて構築され、物理的に分離されたアベイラビリティーゾーン(AZ)のエンジニアリングや継続的なインフラストラクチャ容量計画などの予防的リスク軽減戦略の重要な要素を検討するために拡張されます。

AWSの緊急時対応計画とインシデント対応プレイブックは維持され、更新されて、新たな継続性リスクと過去のインシデントから学んだ教訓が反映されます。プランは、予定されているビジネスコース(少なくとも月1回)でテストおよび更新され、AWSレジリエンシープランは、上級幹部が毎年レビューおよび承認します。

AWSは、システムの可用性を維持し、障害が発生した場合にサービスを回復するために必要な重要なシステムコンポーネントを特定しました。重要なシステムコンポーネント(例:コードベース)は、アベイラビリティーゾーンと呼ばれる複数の隔離された場所にバックアップされます。各アベイラビリティーゾーンは、物理的に異なる独立したインフラストラクチャで実行され、信頼性が高くなるように設計されています。発電機や冷却装置などの一般的な障害ポイントは、アベイラビリティーゾーン間で共有されません。さらに、アベイラビリティーゾーンは物理的に分離されており、火災、竜巻、洪水などの非常に珍しい災害が1つのアベイラビリティーゾーンにのみ影響を与えるように設計されています。AWSは複数のアベイラビリティーゾーン間で重要なシステムコンポーネントを複製し、複製を確実に成功させるために信頼できるバックアップが維持および監視されます。

AWSは、可用性のコミットメントと要件をサポートするために必要なプロジェクトインフラストラクチャに対するサービスの使用状況を継続的に監視しています。AWSは、少なくとも月1回、通常はより頻繁に(週1回など)インフラストラクチャの使用状況と需要を評価する容量計画モデルを維持しています。さらに、AWSキャパシティプランニングモデルは、現在のリソースと予測される要件に基づいて追加のリソースを取得して実装するための将来の需要の計画をサポートします。

アベイラビリティーゾーンと地理的に分散したリージョン、および多数のAWSサービス機能を組み合わせて使用​​することで、復元力のあるアプリケーションとプラットフォームを設計および設計する機能が提供されます。AWSのお客様は、アーキテクチャが複数の障害シナリオに向けて設計されている場合、前述の回復力機能の恩恵を受けます。

保証アプローチ

物理的な復元力と可用性のサブ原則および関連プロセスは、AWSコンプライアンスプログラム内で個別に検証されません。Cloud Security Principlesガイダンスで選択できるように提供された代替案に基づくと、物理的な回復力と可用性に関する制御は、それらを個別に検証するための既存の認定プログラム内には存在しません。AWSは、サービスの可用性に関する最新の情報をstatus.aws.amazon.comで公開しています。AWSは、リージョン固有の要件に関してサービスプロバイダーアサーションを使用します。

原則3:消費者間の分離

実装アプローチ

お客様のシステムとデータの機密性、整合性、可用性を保護することは、お客様の信頼と信頼を維持することと同様に、AWSにとって最も重要です。AWSは、複数レベルのセキュリティを使用して、データの他の十分な分離とサービスの管理がサービスの他のコンシューマーから存在するという信頼を提供することを目指しています。

複数レベルのセキュリティ

Amazon EC2内のセキュリティは、ホストプラットフォームのオペレーティングシステム(OS)、仮想インスタンスOSまたはゲストOS、ファイアウォール、署名付きAPI呼び出しなど、複数のレベルで提供されます。これらの各アイテムは、他のアイテムの機能に基づいています。これにより、Amazon EC2に含まれるデータが不正なシステムまたはユーザーに傍受されるのを防ぎ、構成の柔軟性を犠牲にすることなく、可能な限り安全なAmazon EC2インスタンスを提供できます。

他のテナントによるパケットスニッフィング:仮想インスタンスは、プロミスキャスモードで実行されている他のインスタンスが、別の仮想インスタンスを対象としたトラフィックを受信または「スニッフィング」するのを防ぐように設計されています。顧客は無差別モードにインターフェースを置くことができますが、ハイパーバイザーは彼らに宛てられていないトラフィックを顧客に配信しません。同じ物理ホスト上にある同じ顧客が所有する2つの仮想インスタンスでさえ、互いのトラフィックをリッスンすることはできません。Amazon EC2は、不注意または故意に別のデータを表示しようとする顧客を保護しますが、標準的な方法として、顧客は機密トラフィックを暗号化できます。

お客様のインスタンスはrawディスクデバイスにアクセスできませんが、代わりに仮想ディスクが提供されます。AWS独自のディスク仮想化レイヤーは、ストレージのすべてのブロックを自動的に消去してから使用できるようにします。これにより、ある顧客のデータが意図せずに別の顧客に公開されるのを防ぎます。顧客は、従来のファイルシステム暗号化メカニズムを使用してデータをさらに保護するか、Elastic Block Store(EBS)ボリュームの場合はAWS管理のディスク暗号化を有効にすることができます。

ファイアウォール

Amazon EC2は、セキュリティグループと呼ばれる完全なファイアウォールソリューションを提供します。この必須の受信ファイアウォールはデフォルトの全拒否モードで構成されており、Amazon EC2のお客様は、受信トラフィックを許可するために必要なポートを明示的に開く必要があります。トラフィックは、プロトコル、ポート、およびソース(個々のIPまたはクラスレスドメイン間ルーティング(CIDR)サブネット、または別の顧客定義のセキュリティグループ)の任意の組み合わせによって制限される場合があります。Virtual Private Cloud(VPC)でインスタンスを起動するお客様は、インスタンスからの送信トラフィックの制限などの追加機能にもアクセスできます。

VPCはAWSクラウドの分離された部分であり、その中で顧客はAmazon EC2インスタンスをサブネットにデプロイして(顧客が指定した)VPCのIPアドレス範囲をセグメント化し、あるサブネットのAmazon EC2インスタンスを別のサブネットに分離できます。VPC内のAmazon EC2インスタンスには、VPCに対して確立されたIPsec仮想プライベートネットワーク(VPN)接続を介してのみ顧客がアクセスできます。

保証アプローチ

消費者の原則と関連プロセスの分離は、AWS コンプライアンスプログラム内で個別に検証されません。Cloud Security Principlesガイダンスで選択できるように提供された代替案に基づくと、物理的な回復力と可用性に関する制御は、それらを個別に検証するための既存の認定プログラム内には存在しません。AWSは、リージョン固有の要件に関してサービスプロバイダーアサーションを使用します。

原則4:ガバナンスのフレームワーク

実装アプローチ

AWSのコンプライアンスおよびセキュリティチームは、情報および関連テクノロジの制御目標(COBIT)フレームワークに基づいて情報セキュリティフレームワークとポリシーを確立し、ISO 27002制御に基づいたISO 27001認定可能なフレームワーク、American Institute of Certified Public Accountants(AICPA)を効果的に統合しました)Trust Services Principles、PCI DSS v3.0、およびNational Institute of Standards and Technology(NIST)Publication 800-53 Rev 4(Recommended Security Controls for Federal Information Systems)。AWSはセキュリティポリシーを維持し、従業員にセキュリティトレーニングを提供し、アプリケーションのセキュリティレビューを実行します。これらのレビューでは、データの機密性、整合性、可用性、および情報セキュリティポリシーへの適合性を評価します。

世界的に認められているガバナンスフレームワークの一部として、AWSはAWSインフラストラクチャ、データセンター、および多くのサービスをカバーする情報セキュリティ管理システム(ISMS)のISO 27001:2013認証を取得しています。ISO 27001/27002は、広く採用されているグローバルセキュリティ標準であり、絶え間なく変化する脅威シナリオに適した定期的なリスク評価に基づいて、企業と顧客の情報を管理する体系的なアプローチの要件とベストプラクティスを定めています。するために認証を達成、同社は、企業と顧客情報の機密性、完全性、可用性に影響を与える情報セキュリティ上のリスクを管理するための体系的かつ継続的なアプローチを持って示さなければなりません。この認定により、セキュリティ管理と実践に関する重要な情報を提供するというAmazonの取り組みが強化されます。AWSのISO 27001:2013認定には、世界中のすべてのリージョンのすべてのAWSデータセンターが含まれ、AWSは認定を維持するための正式なプログラムを確立しています。

AWSには、AWSセキュリティチームが管理する確立された情報セキュリティ組織があり、AWS最高情報セキュリティ責任者(CISO)が主導しています。AWSセキュリティは、AWSプラットフォームとインフラストラクチャホストへの論理アクセスの最低基準を明確にするための正式なポリシーと手順を確立および維持します。ポリシーは、論理アクセスとセキュリティの管理に関する機能的責任も識別します。該当する場合、AWS Securityは、Amazon Corporate Information Securityによって確立および維持される情報システムフレームワークとポリシーを活用します。

前述のプロセスは、あなたのAWSサービスのための場所でのガバナンスのフレームワークとプロセスがそれを自分の意図した使用のために適切であることを十分に確信を提供することを目指しています。

保証アプローチ

AWSサービス内のガバナンスフレームワークの原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認証プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。ガバナンスのフレームワークに関連する統制は、認証プログラムの下で少なくとも年1回独立して検証されます。

原則5:運用上のセキュリティ

5.1構成と変更管理

実装アプローチ
ソフトウェア

AWSは体系的なアプローチを適用して変更を管理し、顧客に影響を与えるサービスへの変更がレビュー、テスト、承認され、十分に伝達されるようにします。

変更管理(CM)プロセスは、Amazon変更管理ガイドラインに基づいており、各AWSサービスの詳細に合わせて調整されています。これらのプロセスは文書化され、サービスチームの管理者によって必要な担当者に伝達されます。

AWSの変更管理プロセスの目標は、意図しないサービスの中断を防ぎ、顧客へのサービスの完全性を維持することです。変更の詳細は、AmazonのCMワークフローツールまたは別の変更管理ツールやデプロイメントツールに記載されています。本番環境にデプロイされる変更は次のとおりです。

  • レビュー済み:変更の技術的側面のピアレビュー
  • テスト済み:適用すると期待どおりに動作し、パフォーマンスに悪影響を与えません
  • 承認済み:サービスオーナー(管理)によるビジネスへの影響を適切に監視および理解します。

変更は通常、影響が最も少ないサイトから始めて、段階的な展開で本番環境にプッシュされます。展開は綿密に監視されるため、影響を評価できます。サービスオーナーは、サービスのアップストリーム依存関係の状態を測定する設定可能なメトリックをいくつか持っています。これらのメトリクスは、適切なしきい値と警告(例:待ち時間、可用性、致命的なエラー、CPU使用率など)を使用して綿密に監視されます。ロールバック手順は、変更管理(CM)チケットまたはその他の変更管理ツールに記載されています。

可能な場合、変更は定期的な変更ウィンドウの間にスケジュールされます。標準の変更管理手順からの逸脱を必要とする本番システムへの緊急の変更はインシデントに関連付けられ、必要に応じてログに記録され、承認されます。

インフラ

AWSが内部で開発した構成管理ソフトウェアは、新しいハードウェアがプロビジョニングされるときにインストールされます。これらのツールはすべてのホストで実行され、構成されていること、およびソフトウェアがホストクラスに基づいて標準的な方法でインストールされ、定期的に更新されていることを検証します。承認されたシステムエンジニアと、権限サービスを通じて承認された追加の当事者のみが、中央構成管理サーバーにログインできます。

既存のAWSインフラストラクチャに対する緊急の非日常的およびその他の構成変更は、同様のシステムの業界基準に従って承認、ログ、テスト、承認、および文書化されます。AWSインフラストラクチャの更新は、ほとんどの場合、お客様やサービスの使用に影響を与えないように行われます。AWSは、サービスの使用に悪影響が及ぶ可能性がある場合、EメールまたはAWSサービスヘルスダッシュボード(http://status.aws.amazon.com)を通じてお客様と通信します。

保証アプローチ

AWSサービス内の構成および変更管理の原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。構成および変更管理に関連する制御は、少なくとも毎年、認定プログラムの下で個別に検証されます。

5.2脆弱性管理

実装アプローチ

AmazonWeb Servicesは、AWSクラウドで提供されるすべてのサービスを実行するグ​​ローバルインフラストラクチャの保護を担当します。このインフラストラクチャの保護はAWSの最優先事項です。AWS Securityは、インターネットに面するすべてのサービスエンドポイントIPアドレスを定期的にスキャンして脆弱性をチェックします(これらのスキャンには顧客インスタンスは含まれません)。AWSセキュリティは、特定された多くの脆弱性を修正するよう適切な関係者に通知します。さらに、外部の脆弱性脅威評価は、独立したセキュリティ会社によって定期的に実行されます。これらの評価から得られた調査結果と推奨事項は分類され、AWSのリーダーシップに提供されます。これらのスキャンは、基盤となるAWSインフラストラクチャの正常性と実行可能性を考慮した方法で行われ、特定のコンプライアンス要件を満たすために必要な顧客自身の脆弱性スキャンに代わるものではありません。顧客は、クラウドインフラストラクチャの行動スキャンに許可を要求することができます限り、彼らは顧客のインスタンスに制限されており、AWSに利用規定に違反していません。これらのタイプのスキャンの事前承認は、AWSの脆弱性/侵入テストリクエストフォームからリクエストを送信することで開始できます。

さらに、AWSコントロール環境は、定期的な内部および外部のリスク評価の対象となります。AWSは、外部の認定機関および独立した監査人と協力して、AWS全体の制御環境を確認およびテストします。

保証アプローチ

AWSサービス内の脆弱性管理の原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。脆弱性管理に関連する制御は、認証プログラムの下で少なくとも年1回独立して検証されます。

5.3保護モニタリング

実装アプローチ

AWS内のシステムは、主要な運用およびセキュリティ指標を監視するために広範囲に装備されています。アラームは、主要なメトリックで早期警告しきい値を超えたときに、運用および管理担当者に自動的に通知するように構成されています。しきい値を超えると、AWSインシデント対応プロセスが開始されます。アマゾンインシデントレスポンスチームは、業界標準の診断手順を採用して、ビジネスに影響を与えるイベントの解決を推進します。スタッフは24時間365日体制でインシデントを検出し、解決への影響を管理します。

AWSセキュリティモニタリングツールは、分散攻撃、フラッディング攻撃、ソフトウェア/ロジック攻撃など、いくつかのタイプのサービス拒否(DoS)攻撃の識別に役立ちます。DoS攻撃が特定されると、AWSインシデント対応プロセスが開始されます。DoS防止ツールに加えて、各地域の冗長な通信プロバイダー、および追加の容量により、DoS攻撃の可能性から保護されます。

保証アプローチ

AWSサービス内の保護監視の原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査を受ける必要があります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。防護監視に関連する統制は、少なくとも毎年、認証プログラムの下で独立して検証されます。

5.4インシデント管理

実装アプローチ

AWSは、文書化された正式なインシデント対応ポリシーとプログラムを実装しています。このポリシーは、目的、範囲、役割、責任、および経営陣の取り組みに対応しています。

AWSは3段階のアプローチを使用してインシデントを管理します。

  1. アクティベーションと通知フェーズ:AWSのインシデントは、イベントの検出から始まります。これは、次のようないくつかのソースから発生する可能性があります。
    1. メトリックスとアラーム-AWSは例外的な状況認識機能を維持しており、ほとんどの問題は24時間365日、リアルタイムのメトリックスとサービスダッシュボードのモニタリングとアラームから迅速に検出されます。インシデントの大部分はこの方法で検出されます。AWS は早期インジケーターアラームを利用して、最終的にお客様に影響を与える可能性のある問題を事前に特定します。
    2. AWS従業員が入力したトラブルチケット
    3. 24時間年中無休のテクニカルサポートホットラインへの電話。イベントがインシデント基準を満たしている場合、関連するオンコールサポートエンジニアがAWSイベント管理ツールシステムを利用してエンゲージメントを開始し、エンゲージメントを開始して関連するプログラムリゾルバー(セキュリティチームなど)を呼び出します。リゾルバーはインシデントの分析を実行して、追加のリゾルバーが関与する必要があるかどうかを判断し、おおよその根本原因を判別します。
  2. 回復フェーズ:関連するリゾルバは、インシデントに対処するためにブレークフィックスを実行します。トラブルシューティング、不具合の修正、影響を受けるコンポーネントに対処したら、コールリーダーがフォローアップドキュメントとフォローアップアクションの観点から次のステップを割り当て、コールエンゲージメントを終了します。
  3. 再構成フェーズ:関連する修正アクティビティが完了すると、コールリーダーはリカバリフェーズが完了したことを宣言します。インシデントの事後分析と根本原因の分析は、関連チームに割り当てられます。事後分析の結果は、関連する上級管理職によってレビューされ、設計変更などの関連するアクションがエラー修正(COE)ドキュメントに取り込まれ、完了まで追跡されます。

上記の内部通信メカニズムに加えて、AWSは顧客ベースとコミュニティをサポートするために、外部通信のさまざまな方法も実装しています。カスタマーエクスペリエンスに影響する運用上の問題をカスタマーサポートチームに通知できるようにするメカニズムが用意されています。「サービスヘルスダッシュボード」は、カスタマーサポートチームが利用および保守し、広範囲に影響する可能性のある問題についてお客様に警告します。

保証アプローチ

AWSサービス内のインシデント管理サブ原則および関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。インシデント管理に関連する制御は、認定プログラムの下で少なくとも年1回独立して検証されます。

原則6:人員のセキュリティ

実装アプローチ

AWSは、人事チェックのレベルに自信を持っていることを保証するため、AWS施設への従業員の位置とアクセスレベルに見合った従業員の就職前スクリーニングプラクティスの一部として、適用される法律で許可されているように、犯罪歴チェックを実施します。

オンボーディングプロセスの一環として、AWSシステムとデバイスをサポートするすべての担当者は、アクセス権を付与される前に機密保持契約に署名します。さらに、オリエンテーションの一環として、担当者は利用規定およびAmazonビジネス行動倫理規範(行動規範)ポリシーを読んで受け入れる必要があります。

AWSは、AWS情報セキュリティ要件の認識を促進するための従業員トレーニングプログラムを維持しています。すべての従業員には、会社の企業行動規範および倫理規範が提供され、定期的な情報セキュリティトレーニングを修了します。修了には確認が必要です。コンプライアンス監査は定期的に実施され、従業員が確立されたポリシーを理解して従うことを検証します。

保証アプローチ

AWSサービス内の人的セキュリティの原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認証プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。人員のセキュリティに関する管理は、少なくとも毎年、認定プログラムの下で独立して検証されます。foを提供する代替案に基づいて、Rのクラウドセキュリティ原則のガイダンス内の選択、AWSは、地域固有の要件に関して、サービスプロバイダのアサーションを使用しています。

原則7:安全な開発

実装アプローチ

AWSの開発プロセスは、AWSソフトウェアチームによる正式な設計レビュー、脅威のモデリング、リスク評価の完了など、安全なソフトウェア開発のベストプラクティスに従っています。静的コード分析ツールは標準ビルドプロセスの一部として実行され、展開されたすべてのソフトウェアは、厳選された業界の専門家によって実行される定期的な侵入テストを受けます。当社のセキュリティリスク評価レビューは設計段階で始まり、継続的な運用の開始まで関与が続きます。

また、詳細については、ISO 27001:2013規格の付録A、ドメイン12.5を参照してください。AWSは、ISO 27001認定基準との整合性を確認するために、独立監査人によって検証および認定されています。

保証アプローチ

AWSサービス内の安全な開発原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認証プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。安全な開発に関連する制御は、認証プログラムの下で少なくとも年に1回独立して検証されます。

原則8:サプライチェーンのセキュリティ

実装アプローチ

ISO 27001標準に沿って、AWSハードウェア資産には所有者が割り当てられ、AWS専有の在庫管理ツールを使用してAWS担当者によって追跡および監視されます。AWS調達およびサプライチェーンチームは、すべてのAWSサプライヤーとの関係を維持しています。

AWSのシステムとデバイスをサポートするサードパーティプロバイダーの人的セキュリティ要件は、AWSの親組織であるAmazon.comとそれぞれのサードパーティプロバイダーとの間の相互機密保持契約で定められています。AmazonリーガルカウンセルとAWS調達チームは、サードパーティプロバイダーとの契約に基づいて、AWSサードパーティプロバイダーの人材セキュリティ要件を定義します。AWS 情報を扱うすべての人は、AWS 情報へのアクセスを許可される前に、最低でも、雇用前の身元調査のスクリーニングプロセスを満たし、非開示契約(NDA)に署名する必要があります。

ISO 27001 規格を参照してください。詳細については、付録A、ドメイン7.1。AWSは、ISO 27001認定基準との整合性を確認するために、独立監査人によって検証および認定されています。

ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認証プログラムに基づきます。

保証アプローチ

これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。サプライチェーンのセキュリティに関連する制御は、認証プログラムの下で少なくとも年1回独立して検証されます。

原則9:安全な消費者管理

実装アプローチ

AWS Identity and Access Management(IAM)は、認証および承認されたユーザーが指定されたサービスとインターフェイスにアクセスできるという信頼を提供するための制御と機能を提供します。AWS IAMでは、複数のユーザーを作成し、AWSアカウント内のこれらの各ユーザーのアクセス許可を管理できます。ユーザーは、AWSサービスへのアクセスに使用できる一意のセキュリティ認証情報を持つ(AWSアカウント内の)IDです。AWS IAMを使用すると、パスワードやキーを共有する必要がなくなり、必要に応じてユーザーのアクセスを簡単に有効または無効にできます。

AWS IAMを使用すると、AWSアカウント内のすべてのユーザーに一意の認証情報を付与し、ユーザーがジョブを実行するために必要なAWSサービスとリソースにアクセスするためのアクセス許可のみを付与することで、最小特権などのセキュリティのベストプラクティスを実装できます。AWS IAMはデフォルトで安全です。権限が明示的に付与されるまで、新しいユーザーはAWSにアクセスできません。

AWS IAMはAWS Marketplaceにも統合されているため、Marketplaceで提供されるソフトウェアとサービスに組織の誰がサブスクライブできるかを制御できます。マーケットプレイスで特定のソフトウェアをサブスクライブすると、EC2インスタンスが起動してソフトウェアを実行するため、これは重要なアクセス制御機能です。AWS IAMを使用してAWS Marketplaceへのアクセスを制御することで、AWSアカウントの所有者は、使用量とソフトウェアのコストをきめ細かく制御することもできます。

AWS IAMを使用すると、AWSアカウント認証情報の使用を最小限に抑えることができます。AWS IAMユーザーアカウントを作成すると、AWSサービスおよびリソースとのすべてのやり取りは、AWS IAMユーザーセキュリティ認証情報で発生するはずです。AWS IAMの詳細については、AWSウェブサイトhttp://aws.amazon.com/iam/をご覧ください。

IAMロールを使用してAWSサービスへのAPIアクセスを委任する

AWSは、AWS Identity and Access Management(IAM)ロールをIAMユーザーと組み合わせて非常に重要で強力なユースケースをサポートし、アカウント間のクロスアカウントAPIアクセスまたはAPIアクセスの委任を可能にします。この機能により、複数のAWSアカウントにまたがってサービスとリソースを管理する際の制御が向上し、アクセス管理が簡素化されます。長期間のセキュリティ認証情報を共有しなくても、アカウント内または複数のアカウント間で、クロスアカウントAPIアクセスまたは委任APIアクセスを有効にできます。

IAMロールを引き受けると、そのロールに関連付けられたアクセス許可を持つ一時的なセキュリティ認証情報のセットを取得します。AWSサービスの呼び出しでは、長期的なセキュリティ認証情報の代わりにこれらの一時的なセキュリティ認証情報を使用します。ユーザーは、想定されるIAMロールに付与された権限でサービスと対話します。これにより、作成および管理するユーザー資格情報が少なくなり、ユーザーが複数のパスワードを覚える必要がなくなるため、潜在的な攻撃対象領域が減少します。

保証アプローチ

AWSサービス内の安全な消費者管理サブ原則および関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。安全な消費者管理に関連する統制は、少なくとも毎年、認証プログラムの下で独立して検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

9.2管理インターフェース内の分離とアクセス制御

実装アプローチ

インスタンスの起動と終了、ファイアウォールパラメータの変更、その他の機能を実行するAPI呼び出しはすべて、Amazonシークレットアクセスキーによって署名されます。これは、AWSアカウントシークレットアクセスキーまたはAWS IAMで作成されたユーザーのシークレットアクセスキーのいずれかです。シークレットアクセスキーにアクセスできない場合、Amazon EC2 API呼び出しを代行することはできません。さらに、API呼び出しをSSLで暗号化して機密性を維持できます。Amazonでは、常にSSLで保護されたAPIエンドポイントを使用することをお勧めします。

AWS IAMを使用すると、ユーザーが特定のリソースを管理するために呼び出すアクセス許可を持つAPIをさらに制御することもできます。

ID管理を改善するためのクロスアカウントアクセス

AWSでは、役割を引き受けることは、AWSリソースでアクションを実行するためのアクセス許可を付与するポリシーをユーザーが割り当てることができるセキュリティ原則です。 ユーザーアカウントの場合とは異なり、役割にはサインインしません。代わりに、ユーザーとして既にサインインしていて、ロールに切り替えて、一時的に元のユーザー権限を放棄し、ロールの権限を引き継ぎます。役割の使用が終了すると、ユーザーの権限に再び戻ります。

IAMユーザーガイドに記載されているように、管理者は、管理するリソースを持つアカウントにロールを作成し、そのロールを使用することが信頼されているAWSアカウントIDを指定します。次に、信頼できるアカウントの管理者は、役割に切り替えることができる特定のユーザーに権限を付与します。

この方法でロールを介してアクセスを委任すると、資格情報の管理が簡素化され、セキュリティ体制を改善するのに役立ちます。ユーザーは、アクセスする必要があるすべてのアカウントのサインイン資格情報をユーザーに提供する必要はなく、1セットのサインイン資格情報のみが必要です。これにより、作成および管理する必要があるユーザー資格情報が少なくなり、ユーザーが複数のパスワードを覚える必要がなくなるため、潜在的な攻撃対象領域が減少します。

この機能を使用して、単一アカウント内のセキュリティを向上させることができます。一般的なユーザーを作成するときは、そのユーザーに、仕事に必要なすべてのリソース(最も機密性が高く、ほとんどアクセスされないリソース)にアクセスするためのアクセス許可を与えます。理想的には、ユーザーは、「最低限のアクセス」というセキュリティ原則を維持する必要が実際にあるまで、機密性の高い重要なリソースへのアクセス権を持たないようにする必要があります。権限を役割に委任し、ユーザーに役割への切り替えを許可する機能は、このジレンマを解決します。機密性の高いリソースではなく、通常の日常の管理対象リソースへのアクセスを許可する権限のみをユーザーに付与します。代わりに、機密性の高いリソースにアクセスするための権限を役割に付与します。ユーザーは、これらのリソースを使用する必要があるときに役割に切り替えてから、ユーザーアカウントに戻すことができます。この機能は、攻撃対象領域を減らすのに役立ちます。

保証アプローチ

AWSサービス内の管理インターフェイスのサブ原則と関連プロセス内の分離とアクセス制御は、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。管理インターフェース内の分離とアクセス制御に関連する制御は、少なくとも毎年、認定プログラムの下で個別に検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

原則10:IDと認証

実装アプローチ

AWSには、ユーザーを識別してAWSアカウントに安全にアクセスするための方法がいくつか用意されています。AWSでサポートされている認証情報の完全なリストは、「アカウント」の「セキュリティ認証情報」ページにあります。AWSは、AWSアカウントをさらに保護してアクセスを制御できるようにする追加のセキュリティオプションも提供します:AWS Identity and Access Management(AWS IAM)、キー管理とローテーション、一時的なセキュリティ認証情報、および多要素認証(MFA)。AWS IAMを使用すると、AWSアカウント認証情報の使用を最小限に抑えることができます。AWS IAMユーザーアカウントを作成すると、AWSサービスおよびリソースとのすべてのやり取りは、AWS IAMユーザーセキュリティ認証情報で発生するはずです。AWS IAMの詳細については、AWSウェブサイトhttp://aws.amazon.com/iam/をご覧ください。

ホストオペレーティングシステム:ビジネスで管理プレーンにアクセスする必要がある管理者は、多要素認証を使用して、専用の管理ホストにアクセスする必要があります。これらの管理ホストは、クラウドの管理プレーンを保護するために特別に設計、構築、構成、および強化されたシステムです。このようなアクセスはすべてログに記録され、監査されます。従業員がビジネスで管理プレーンにアクセスする必要がなくなった場合、これらのホストと関連システムへの特権とアクセス権を取り消すことができます。

ゲストオペレーティングシステム:仮想インスタンスは、お客様であるお客様によって完全に制御されます。アカウント、サービス、およびアプリケーションに対する完全なrootアクセス権または管理制御権があります。AWSには、インスタンスまたはゲストOSへのアクセス権はありません。AWSは、ゲストへのパスワードのみのアクセスを無効にし、インスタンスへのアクセスを取得するために何らかの形式の多要素認証を利用すること(または最低限の証明書ベースのSSHバージョン2アクセス)を含むセキュリティのベストプラクティスの基本セットをお勧めします。さらに、ユーザーごとにログを記録する特権昇格メカニズムを採用する必要があります。たとえば、ゲストOSがLinuxの場合、インスタンスを強化した後、証明書ベースのSSHv2を使用して仮想インスタンスにアクセスし、リモートルートログインを無効にし、コマンドラインロギングを使用し、特権の昇格には「sudo 」を使用します。一意であり、他の顧客やAWSと共有されないことを保証するために、独自のキーペアを生成する必要があります。

AWSは、Secure Shell(SSH)ネットワークプロトコルの使用もサポートしており、EC2インスタンスに安全にログインできます。AWSで使用されるSSHの認証は、インスタンスへの不正アクセスのリスクを軽減するために公開鍵/秘密鍵のペアを介して行われます。インスタンス用に生成されたRDP証明書を利用して、リモートデスクトッププロトコル(RDP)を使用してWindows インスタンスにリモートで接続することもできます。

AWS IAMを使用すると、AWSアカウント内のすべてのユーザーに一意の認証情報を付与し、ユーザーがジョブを実行するために必要なAWSサービスとリソースにアクセスするためのアクセス許可のみを付与することで、最小特権などのセキュリティのベストプラクティスを実装できます。AWS IAMはデフォルトで安全です。権限が明示的に付与されるまで、新しいユーザーはAWSにアクセスできません。

AWS IAMはAWS Marketplaceにも統合されているため、Marketplaceで提供されるソフトウェアとサービスに組織の誰がサブスクライブできるかを制御できます。マーケットプレイスで特定のソフトウェアをサブスクライブすると、EC2インスタンスが起動してソフトウェアを実行するため、これは重要なアクセス制御機能です。AWS IAMを使用してAWS Marketplaceへのアクセスを制御することで、AWSアカウントの所有者は、使用量とソフトウェアのコストをきめ細かく制御することもできます。

保証アプローチ

AWSサービス内のIDおよび認証の原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。IDと認証に関連する制御は、少なくとも毎年、認定プログラムの下で個別に検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

原則11:外部インターフェース保護

実装アプローチ

お客様のシステムとデータの機密性、整合性、可用性を保護することは、お客様の信頼と信頼を維持することと同様に、AWSにとって最も重要です。

AWSネットワークは、ワークロードに適したセキュリティと復元力のレベルを選択できるように設計されています。AWSは、クラウドリソースを使用して地理的に分散したフォールトトレラントなWebアーキテクチャを構築できるように、注意深く監視および管理される世界クラスのネットワークインフラストラクチャを実装しています。

安全なネットワーク

建築

ファイアウォールやその他の境界デバイスを含むネットワークデバイスは、ネットワークの外部境界およびネットワーク内の主要な内部境界で通信を監視および制御するために設置されています。これらの境界デバイスは、ルールセット、アクセス制御リスト(ACL)、および構成を使用して、特定の情報システムサービスへの情報のフローを実施します。ACL、またはトラフィックフローポリシーは、トラフィックのフローを管理および実施する各管理対象インターフェイスで確立されます。ACLポリシーは、Amazon Information Securityによって承認されています。これらのポリシーは、AWSのACL-Manageツールを使用して自動的にプッシュされ、これらの管理対象インターフェイスが最新のACLを適用するようにします。

安全なアクセスポイント

AWSは戦略的にクラウドへのアクセスポイントの数を制限して、インバウンドとアウトバウンドの通信とネットワークトラフィックのより包括的なモニタリングを可能にしています。これらのカスタマーアクセスポイントはAPIエンドポイントと呼ばれ、安全なHTTPアクセス(HTTPS)を許可するため、AWS内のストレージまたはコンピューティングインスタンスとの安全な通信セッションを確立できます。さらに、AWSは、インターネットサービスプロバイダー(ISP)とのインターフェース通信の管理専用のネットワークデバイスを実装しています。AWSは、AWSネットワークのインターネットに面した各エッジで、複数の通信サービスへの冗長接続を採用しています。これらの接続にはそれぞれ専用のネットワークデバイスがあります。

トランスミッション保護

盗聴、改ざん、メッセージ偽造から保護するように設計された暗号化プロトコルであるSecure Sockets Layer(SSL)を使用して、HTTPまたはHTTPS経由でAWSアクセスポイントに接続できます。AWSは、ネットワークセキュリティの追加レイヤーを必要とするお客様向けに、AWSクラウド内にプライベートサブネットを提供するAmazon Virtual Private Cloud(VPC)と、IPsec仮想プライベートネットワーク(VPN)デバイスを使用して暗号化されたAmazon VPCとデータセンターの間のトンネルを提供する機能を提供します。

ネットワークの監視と保護

AWSは、さまざまな自動監視システムを利用して、高レベルのサービスパフォーマンスと可用性を提供します。AWSモニタリングツールは、入口および出口の通信ポイントでの異常または無許可のアクティビティおよび状態を検出するように設計されています。これらのツールは、サーバーとネットワークの使用状況、ポートスキャンアクティビティ、アプリケーションの使用状況、不正な侵入の試みを監視します。ツールには、異常なアクティビティのカスタムパフォーマンスメトリックしきい値を設定する機能があります。

AWS内のシステムは、主要な運用指標を監視するために広範囲に装備されています。アラームは、主要な運用メトリックで早期警告しきい値を超えたときに、運用および管理担当者に自動的に通知するように構成されています。オンコールスケジュールが使用されるため、担当者は運用上の問題にいつでも対応できます。これにはポケットベルシステムが含まれているため、アラームは迅速かつ確実に運用担当者に通知されます。

ドキュメントは、インシデントまたは問題の処理において運用担当者を支援および通知するために維持されます。問題の解決にコラボレーションが必要な場合は、通信およびロギング機能をサポートする会議システムが使用されます。訓練を受けたコールリーダーは、コラボレーションを必要とする運用上の問題の処理中に、コミュニケーションと進行を容易にします。ポストmortemsが重大な運用に関係なく、外部からの衝撃の問題、およびエラーの原因の後に招集されている根本的な原因がされるように(COE)の文書が起草されているキャプチャおよび予防措置が将来的に取られています。予防策の実施は、毎週の運用会議中に追跡されます。

AWSのセキュリティ監視ツールは、分散攻撃、フラッディング攻撃、ソフトウェア/ロジック攻撃など、サービス拒否(DoS)攻撃のいくつかのタイプを特定するのに役立ちます。DoS 攻撃が特定されると、AWSインシデント対応プロセスが開始されます。DoS防止ツールに加えて、各地域の冗長な通信プロバイダーと追加の容量により、DoS攻撃の可能性から保護されます。

保証アプローチ

AWSサービス内の外部インターフェイス保護の原則と関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認証プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。外部インターフェース保護に関連する制御は、認証プログラムの下で少なくとも毎年毎年独立して検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

原則12:安全なサービス管理

実装アプローチ
ユーザーアクセス

Amazonの従業員および請負業者のユーザーアカウントが適時に追加、変更、または無効化され、定期的に見直されるようにするための手順が存在します。さらに、AWSシステムに対するユーザー認証のパスワードの複雑さの設定は、Amazonの企業パスワードポリシーに準拠して管理されます。

アカウントのプロビジョニング

従業員と請負業者のアクセスをプロビジョニングする責任は、人事(HR)、企業運営、およびサービスオーナー全体で共有されます。

最小限の権限を持つ標準の従業員または請負業者のアカウントは、雇用マネージャーがAmazonのHRシステムで新しい従業員または請負業者のオンボーディングリクエストを送信すると、無効な状態でプロビジョニングされます。従業員のレコードがAmazonのHRシステムでアクティブ化されると、アカウントは自動的に有効になります。初回パスワードは一意の値に設定されており、初回使用時に変更する必要があります。

サービス、ホスト、ネットワークデバイス、Windows およびUNIXグループを含む他のリソースへのアクセスは、適切な所有者またはマネージャーによってAmazonの独自のアクセス許可管理システムで明示的に承認されています。アクセスの変更のリクエストは、Amazonアクセス許可管理ツールの監査ログに記録されます。従業員の職務の変更が発生した場合、継続的なアクセスはリソースへの明示的な承認が必要です。そうでない場合、リソースは自動的に取り消されます。

定期的なアカウントのレビュー

アカウントは90日ごとにレビューされます。明示的な再承認が必要か、リソースへのアクセスが自動的に取り消されます。

アクセス削除

AmazonのHRシステムで従業員のレコードが終了すると、アクセスは自動的に取り消されます。WindowsアカウントとUNIXアカウントは無効になり、Amazonのアクセス許可管理システムはユーザーをすべてのシステムから削除します。

パスワードポリシー

Amazonの論理セキュリティへのアクセスと管理は、ユーザーID、パスワード、およびKerberosを使用して、サービス、リソース、デバイスに対してユーザーを認証し、ユーザーに適切なレベルのアクセスを許可します。AWS Securityは、必要な構成と有効期限の間隔でパスワードポリシーを確立しています。

ビジネスで管理プレーンにアクセスする必要がある管理者は、多要素認証を使用して、専用の管理ホストにアクセスする必要があります。これらの管理ホストは、クラウドの管理プレーンを保護するために特別に設計、構築、構成、および強化されたシステムです。そのようなアクセスはすべてログに記録され、監査されます。従業員が管理プレーンにアクセスするビジネス上の必要がなくなった場合、これらのホストと関連システムへの特権とアクセスが取り消されます。

保証アプローチ

安全なサービス管理の原則とAWSサービス内の関連プロセスは、ISO 27001:2013、AICPA SOC 1、SOC 2、SOC 3、およびPCI-DSS認定プログラムに基づいて、少なくとも毎年監査の対象となります。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。安全なサービス管理に関連する制御は、認定プログラムの下で少なくとも年1回独立して検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

原則13:消費者への監査情報の提供

実装アプローチ

AWS CloudTrailは、AWSのお客様に監査レコードを提供し、監査情報をログファイルの形式で指定されたストレージバケットに配信するサービスです。記録される情報には、API呼び出し元のID、API呼び出しの時刻、API呼び出し元のソースIPアドレス、リクエストパラメータ、およびAWSサービスによって返される応答要素が含まれます。

CloudTrailは、AWS管理コンソール、AWS SDK、コマンドラインツール、および上位レベルのAWSサービス(AWS CloudFormationなど)を介して行われたAPI呼び出しを含む、お客様のアカウントのAWS API呼び出しの履歴を提供します。CloudTrailによって生成されたAWS API呼び出し履歴により、セキュリティ分析、リソース変更追跡、コンプライアンス監査が可能になります。

S3に書き込まれたログファイルオブジェクトには、バケット所有者にフルコントロールが付与されます。したがって、バケットの所有者は、ログを他のユーザーと共有するかどうかを完全に制御できます。

この機能はAWSのお客様を可能にし、サービスの誤用やインシデントを調査するためのニーズを満たす自信を提供します。

AWS CloudTrailの詳細と監査レコードの詳細については、http://aws.amazon.com/cloudtrailでリクエストできます。CloudTrailユーザーガイドの最新バージョンは、http: //awsdocs.s3.amazonaws.com/awscloudtrail/latest/awscloudtrail-ug.pdfから入手できます。

保証アプローチ

AWSサービス内の消費者の原則と関連プロセスへの監査情報の提供は、ISO 27001:2013、AICPA SOC 1、SOC 2に基づいて、少なくとも毎年監査を受ける必要があります。

SOC 3およびPCI-DSS認定プログラム。これらの認定は、クラウド認定スキームに基づいてENISAによって認定されています。消費者への監査情報提供に関連する統制は、認証プログラムの下で少なくとも毎年独立して検証されます。Cloud Security Principlesガイダンスで選択できるように提供されている代替案に基づいて、AWSは地域固有の要件に関してサービスプロバイダーアサーションを使用します。

原則14:消費者によるサービスの安全な使用

実装アプローチ

AWSは、お客様と幅広い顧客ベースおよびコミュニティをサポートするために、さまざまな外部通信方法を実装しています。AWSは、AWSサービスの許容可能な使用についてガイダンスを提供し、消費者に通知する、許容可能な使用ポリシーを公開しています。このポリシーには、違法、有害、または不快なコンテンツ、セキュリティ違反、ネットワークの悪用、電子メールまたはメッセージの悪用に関するガイダンスと、ポリシーの監視および実施に関する情報が含まれます。さらに、利用規定の違反の報告に関するガイダンスが提供されます。

カスタマーエクスペリエンスに影響する運用上の問題をカスタマーサポートチームに通知できるようにするメカニズムが用意されています。「サービスヘルスダッシュボード」は、カスタマーサポートチームが利用および保守し、広範囲に影響する可能性のある問題についてお客様に警告します。AWSセキュリティセンターは、AWSのセキュリティとコンプライアンスの詳細を提供するために利用できます。

お客様は、カスタマーサポートチームとの直接のコミュニケーションや、お客様に影響を与える問題に対する予防的なアラートを含むAWSサポートサービスをサブスクライブすることもできます。

Trusted Advisorツールの使用

一部のAWSサポート計画には、Trusted Advisorツールへのアクセスが含まれています。これは、サービスの1ビューのスナップショットを提供し、一般的なセキュリティの誤設定、システムパフォーマンスの改善に関する提案、十分に活用されていないリソースを特定するのに役立ちます。

Trusted Advisorは、次のセキュリティ推奨事項への準拠を確認します。

  • 一般的な管理ポートへのアクセスを、アドレスの小さなサブセットのみに制限します。これには、ポート22(SSH)、23(Telnet)3389(RDP)、および5500(VNC)が含まれます。
  • 一般的なデータベースポートへのアクセス制限。これには、ポート1433(MSSQLサーバー)、1434(MSSQLモニター)、3306(MySQL)、Oracle(1521)および5432(PostgreSQL)が含まれます。
  • IAMは、AWSリソースの安全なアクセス制御を保証するように構成されています。
  • 多要素認証(MFA)トークンが有効になっており、ルートAWSアカウントに2要素認証を提供します。
保証アプローチ

消費者の原則と関連プロセスによるサービスの安全な使用は、AWSコンプライアンスプログラム内で個別に検証されません。Cloud Security Principlesガイダンスで選択のために提供された代替案に基づくと、消費者によるサービスの安全な使用に関する制御は、それらを個別に検証するための既存の認定プログラム内には存在しません。AWSは、ローカルサミットセッション、ウェビナー、ブログ、トレーニングおよびガイダンスドキュメントなどのさまざまなコミュニケーションチャネルを通じて、構成オプションとセキュリティへの相対的な影響に関するガイダンスを定期的に公開しています。AWSは、リージョン固有の要件に関してサービスプロバイダーアサーションを使用します。

結論

AWSクラウドプラットフォームは、英国の公共部門組織にいくつかの重要なメリットを提供し、14のクラウドセキュリティ原則の目的を達成できるようにします。AWSはサービスと機能を通じてこれらの利点と利点を提供しますが、個々の公共部門組織は、公式情報のための安全なクラウドサービスの使用に関するリスク管理の決定に対して最終的に責任があります。このホワイトペーパーに記載されている情報を使用して、組織のセキュリティと関連リスクを適切に管理するためにAWSサービスを使用することをお勧めします。

AWSにとって、セキュリティは常に最優先事項です。当社は、190か国以上の企業、教育機関、政府機関を含む何十万もの企業にサービスを提供しています。当社のお客様には、最も機密性の高い情報を含むデータの管理と責任を保持しながらAWSのメリットを活用する政府機関、金融サービス、ヘルスケアプロバイダーが含まれます。

AWSサービスは、ソリューションの構成とデプロイの方法、およびコンテンツの格納場所、格納方法、コンテンツへのアクセス権とセキュリティ構成環境などのコンテンツを制御する柔軟性をお客様に提供するように設計されています。AWSのお客様は、独自の安全なアプリケーションを構築し、コンテンツをAWSに安全に保存できます。尚、AWSでクラウドファーストなゼロトラストネットワークの実現を目指す場合は他の記事もございますので、是非そちらもご確認ください。

SNSでもご購読できます。

コメントを残す

*