翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ワークロード OU — アプリケーションアカウント

次の図は、アプリケーションアカウント (およびアプリケーション自体) で設定されている AWS セキュリティサービスを示しています。

Application アカウントは、エンタープライズアプリケーションを実行および維持するためのプライマリインフラストラクチャとサービスをホストします。アプリケーションアカウントとワークロード OU は、いくつかの主要なセキュリティ目標を果たします。まず、アプリケーションごとに個別のアカウントを作成して、ワークロード間の境界と制御を提供し、役割、許可、データ、および暗号化キーが発生する問題を回避します。アプリケーションチームに、他のユーザーに影響を与えることなく、独自のインフラストラクチャを管理する幅広い権限を付与できる個別のアカウントコンテナを提供したいと考えています。次に、セキュリティ運用チームがセキュリティデータを監視および収集するメカニズムを提供して、保護のレイヤーを追加します。セキュリティチームによって設定およびモニタリングされるアカウントセキュリティサービス (Amazon GuardDuty、 AWS Config AWS Security Hub CSPM、Amazon EventBridge、IAM Access Analyzer) の組織の証跡とローカルデプロイを採用します。最後に、企業が一元的に制御を設定できるようにします。アプリケーションアカウントは、適切なサービス権限、制約、およびガードレールを継承する Workloads OU のメンバーにして、より広範なセキュリティ構造に合わせます。

アプリケーション VPC

アプリケーションアカウントの Virtual Private Cloud (VPC) には、インバウンドアクセス (モデリングするシンプルなウェブサービス用) とアウトバウンドアクセス (アプリケーションのニーズまたは AWS のサービス ニーズ用) の両方が必要です。デフォルトでは、VPC 内のリソースは相互にルーティング可能です。2 つのプライベートサブネットがあります。1 つは EC2 インスタンス (アプリケーションレイヤー) をホストし、もう 1 つは Amazon Aurora (データベースレイヤー) をホストします。アプリケーション層やデータベース層など、異なる層間のネットワークセグメンテーションは、インスタンスレベルでトラフィックを制限する VPC セキュリティグループを介して行われます。復元力のために、ワークロードは複数のアベイラビリティーゾーンにまたがり、ゾーンごとに 2 つのサブネットを使用します。

VPC エンドポイント

VPC endpoints は、スケーラビリティと信頼性だけでなく、セキュリティ制御の別のレイヤーを提供します。これらを使用して、アプリケーション VPC を他の に接続します AWS のサービス。(アプリケーションアカウントでは、SRA AWS は AWS KMS AWS Systems Managerと Amazon S3 の VPC エンドポイントを使用します）。エンドポイントは仮想デバイスです。これらは水平にスケールされ、冗長で、可用性の高い VPC コンポーネントです。これにより、ネットワークトラフィックに可用性リスクや帯域幅の制約を課すことなく、VPC 内のインスタンスとサービス間の通信が可能になります。VPC エンドポイントを使用して、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要と AWS PrivateLink せずに、サポートされている AWS のサービス および を搭載した VPC エンドポイントサービスに VPC をプライベートに接続できます。VPC 内のインスタンスは、他の と通信するためにパブリック IP アドレスを必要としません AWS のサービス。VPC と他の VPC 間のトラフィック AWS のサービス は、Amazon ネットワークを離れません。

VPC エンドポイントを使用するもう 1 つの利点は、エンドポイントポリシーの設定を有効にすることです。VPC エンドポイントポリシーは、エンドポイントの作成時または変更時にエンドポイントに加える IAM リソースポリシーです。エンドポイントの作成時に IAM ポリシーをアタッチしない場合、 はサービスへのフルアクセスを許可するデフォルトの IAM ポリシーをア AWS タッチします。エンドポイントポリシーは、IAM ユーザーポリシーやサービス固有のポリシー (S3 バケットポリシーなど) を上書き、または置き換えません。これは、エンドポイントから指定されたサービスへのアクセスを制御するための別個の IAM ポリシーです。このようにして、どの AWS プリンシパルがリソースまたはサービスと通信できるかを別の制御レイヤーに追加します。

Amazon EC2

アプリケーションを構成する Amazon EC2 インスタンスは、インスタンスメタデータサービス (IMDSv2) のバージョン 2 を使用します。IMDSv2 は、IDMS にアクセスを試みるために使われた、ウェブサイトアプリケーションファイアウォール、オープンリバースプロキシ、サーバーサイドリクエストフォージェリ (SSRF) の脆弱性、オープンレイヤー 3 ファイアウォール、および NAT という 4 種類の脆弱性に対する保護を追加します。さらなる詳細については、ブログ投稿 Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service を参照してください。

(アカウント境界のサブセットとして) 個別の VPCs を使用して、ワークロードセグメント別にインフラストラクチャを分離します。サブネットを使用すると、単一の VPC 内で多階層ウェブアプリケーションの各階層 (ウェブサーバー、アプリケーションサーバーおよびデータベースサーバーなど) を隔離できます。インターネットからの直接アクセスを認めるべきでないインスタンスには、プライベートサブネットを使用します。インターネットゲートウェイを使用せずにプライベートサブネットから Amazon EC2 API を呼び出すには、 を使用します AWS PrivateLink。セキュリティグループを使用してインスタンスへのアクセスを制限します。VPC フローログを使用して、インスタンスに到達するトラフィックをモニタリングします。の一機能である Session Manager を使用して AWS Systems Manager、インバウンド SSH ポートを開いて SSH キーを管理する代わりに、インスタンスにリモートでアクセスします。オペレーティングシステムとデータには、個別の Amazon Elastic Block Store (Amazon EBS) ボリュームを使用します。作成した新しい EBS ボリュームとスナップショットコピーの暗号化を強制するように を設定できます AWS アカウント。 

AWS Nitro Enclaves

AWS Nitro Enclaves は、Amazon EC2 インスタンスから enclaves と呼ばれる独立した実行環境を作成できる Amazon EC2 機能です。Enclaves は、分離された、強化された、制約の厳しい仮想マシンです。単一の親 EC2 インスタンスの CPU とメモリは、分離されたエンクレーブに分割されます。各エンクレーブは独立したカーネルを実行します。エンクレーブは、親インスタンスとの安全なローカルソケット接続のみを提供します。永続的ストレージ、対話型アクセス、外部ネットワークはありません。ユーザーはエンクレーブに SSH 接続できず、エンクレーブ内のデータとアプリケーションには、親インスタンスのプロセス、アプリケーション、またはユーザー (ルートまたは管理者) がアクセスできません。EC2 インスタンス内で、個人を特定できる情報 (PII)、医療、財務、知的財産のデータなど、最も機密性の高いデータを保護できます。Nitro Enclaves を使用すると、外部サービスとの統合を心配することなく、アプリケーションに集中できます。Nitro Enclaves には、承認されたコードのみが実行されていることを確認するためのソフトウェアの暗号化認証と、エンクレーブのみが機密マテリアルにアクセスできる AWS KMS ように との統合が含まれています。これにより、最も機密性の高いデータ処理アプリケーションの攻撃対象領域を減らすことができます。Nitro Enclaves の使用には追加料金はかかりません。

暗号化認証は、エンクレーブのアイデンティティを証明するために使用されるプロセスです。認証プロセスは Nitro Hypervisor を通じて行われます。これにより、エンクレーブの署名付き認証ドキュメントが生成され、そのアイデンティティが別のサードパーティーまたはサービスに証明されます。認証ドキュメントには、エンクレーブのパブリックキー、エンクレーブイメージとアプリケーションのハッシュなど、エンクレーブのキーの詳細が含まれています。

Nitro Enclaves 用の AWS Certificate Manager (ACM) を使用すると、Nitro Enclaves で EC2 インスタンスで実行されているウェブアプリケーションとウェブサーバーでパブリックおよびプライベート SSL/TLS 証明書を使用できます。SSL/TLS 証明書は、ネットワーク通信を保護し、インターネット経由でウェブサイトのアイデンティティを確立し、プライベートネットワーク上のリソースを確立するために使用されます。ACM for Nitro Enclaves は、SSL/TLS 証明書の購入、アップロード、更新の時間がかかり、エラーが発生しやすい手動プロセスを削除します。ACM for Nitro Enclaves は、安全なプライベートキーを作成し、証明書とそのプライベートキーをエンクレーブに配布し、証明書の更新を管理します。ACM for Nitro Enclaves では、証明書のプライベートキーはエンクレーブ内で分離されたままになるため、インスタンスとそのユーザーがアクセスできなくなります。詳細については、AWS Certificate Manager Nitro Enclaves ドキュメントの「 for Nitro Enclaves」を参照してください。

アプリケーション ロード バランサー

アプリケーションロードバランサーは、受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの EC2 インスタンスなどの複数のターゲットに分散します。 AWS SRA では、ロードバランサーのターゲットグループはアプリケーション EC2 インスタンスです。 AWS SRA は HTTPS リスナーを使用して、通信チャネルが暗号化されていることを確認します。Application Load Balancer はサーバー証明書を使用してフロントエンド接続を終了し、ターゲットにリクエストを送信する前に、クライアントからのリクエストを復号化します。

AWS Certificate Manager (ACM) は Application Load Balancer とネイティブに統合され、SRA AWS は ACM を使用して必要な X.509 (TLS サーバー) パブリック証明書を生成および管理します。Application Load Balancer セキュリティポリシーを通して、フロントエンド接続に TLS 1.2 と強力な暗号を適用できます。詳細については、「Elastic Load Balancing ドキュメント」を参照してください。

AWS Private CA

AWS Private Certificate Authority (AWS Private CA) は、Application Load Balancer で使用するプライベート証明書を生成するために Application アカウントで使用されます。Application Load Balancer が TLS 経由で安全なコンテンツを提供する一般的なシナリオです。これには、Application Load Balancer に TLS 証明書をインストールする必要があります。厳密に内部のアプリケーションの場合、プライベート TLS 証明書は安全なチャネルを提供できます。

AWS SRA では、 AWS Private CA は Security Tooling アカウントでホストされ、 を使用してアプリケーションアカウントに共有されます AWS RAM。これにより、アプリケーションアカウントのデベロッパーは、共有プライベート CA から証明書をリクエストできます。組織全体または組織全体で CAs を共有する AWS アカウント と、すべての で重複CAs を作成および管理する際のコストと複雑さが軽減されます AWS アカウント。ACM を使用して共有 CA からプライベート証明書を発行すると、証明書はリクエスト元のアカウントでローカルに生成され、ACM は完全なライフサイクル管理と更新を提供します。

Amazon Inspector

AWS SRA は Amazon Inspector を使用して、Amazon Elastic Container Registry (Amazon ECR) に存在する EC2 インスタンスとコンテナイメージを自動的に検出してスキャンし、ソフトウェアの脆弱性や意図しないネットワークへの露出 がないか確認します。

Amazon Inspector は、このアカウントの EC2 インスタンスに脆弱性管理サービスを提供するため、アプリケーションアカウントに配置されます。さらに、Amazon Inspector は EC2 インスタンスとの間の不要なネットワークパスをレポートします。

メンバーアカウントの Amazon Inspector は、委任管理者アカウントによって一元管理されます。SRA では、Security Tooling AWS アカウントは委任管理者アカウントです。委任管理者アカウントは、組織のメンバーの検出結果データと特定の設定を管理できます。これには、すべてのメンバーアカウントの集計結果の詳細の表示、メンバーアカウントのスキャンの有効化または無効化、 AWS 組織内のスキャンされたリソースの確認が含まれます。

AWS Systems Manager

AWS Systems Manager は、 AWS のサービス 複数の からの運用データを表示 AWS のサービス し、 AWS リソース全体の運用タスクを自動化するために使用できる です。自動承認ワークフローとランブックを使用すると、人為的ミスを減らし、 AWS リソースのメンテナンスとデプロイタスクを簡素化できます。

これらの一般的な自動化機能に加えて、Systems Manager は、予防、detective な、および応答性の高いセキュリティ機能を多数サポートしています。AWS Systems Manager エージェント (SSM エージェント) は、EC2 インスタンス、オンプレミスサーバー、または仮想マシン (VM) にインストールして設定できる Amazon ソフトウェアです。SSM Agent により、Systems Manager がこれらのリソースを更新、管理、および設定できるようにします。Systems Manager は、これらのマネージドインスタンスをスキャンし、パッチ、設定、カスタムポリシーで検出された違反を報告する (または是正措置を講じる) ことで、セキュリティとコンプライアンスを維持するのに役立ちます。

SRA は、Systems Manager AWS の一機能である Session Manager を使用して、インタラクティブなブラウザベースのシェルと CLI エクスペリエンスを提供します。 https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.htmlこれにより、インバウンドポートを開いたり、baston ホストを維持したり、SSH キーを管理したりすることなく、安全で監査可能なインスタンス管理が提供されます。 AWS SRA は、Systems Manager の一機能である Patch Manager を使用して、オペレーティングシステムとアプリケーションの両方の EC2 インスタンスにパッチを適用します。

また、SRA は Systems Manager AWS の一機能である Automation を使用して、Amazon EC2 インスタンスやその他の AWS リソースの一般的なメンテナンスおよびデプロイタスクを簡素化します。オートメーションは、1 つ以上のノードの状態を変更 (承認されたオートメーションを使用) したり、スケジュールに従ってノードの状態を管理するなどの一般的な IT タスクを簡略化できます。Systems Manager には、タグを使用したインスタンスの大規模なグループのターゲットに役立つ機能や定義する制限に応じた変更を行うために役立つ速度制御といった機能が含まれます。Automation は、golden Amazon マシンイメージ (AMI) の作成や到達不可能な EC2 インスタンスの復元などの複雑なタスクを簡素化する、ワンクリックAutomation を提供します。さらに、IAM ロールに特定の関数を実行するための特定のランブックへのアクセスを許可することで、運用セキュリティを強化できます。これらのロールに直接アクセス許可を付与する必要はありません。たとえば、IAM ロールにパッチ更新後に特定の EC2 インスタンスを再起動するアクセス許可を付与したいが、そのロールに直接アクセス許可を付与しない場合は、代わりに Automation ランブックを作成し、そのロールにランブックのみを実行するアクセス許可を付与できます。

Amazon Aurora

AWS SRA では、Amazon Aurora と Amazon S3 が論理データ層を構成します。Aurora はフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。EC2 インスタンスで実行されているアプリケーションは、必要に応じて Aurora および Amazon S3 と通信します。Aurora は DB サブネットグループ内のデータベースクラスターで構成されます。

Amazon S3

Amazon S3 は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。これは、 上に構築された多くのアプリケーションのデータバックボーンであり AWS、機密データを保護するために適切なアクセス許可とセキュリティコントロールが不可欠です。Amazon S3 の推奨されるセキュリティのベストプラクティスについては、documentation、 online tech talks、および blog posts 中のより深いダイブインを参照します。最も重要なベストプラクティスは、S3 バケットへの過度に許容されるアクセス（特にパブリックアクセス）をブロックすることです。

AWS KMS

AWS SRA は、キー管理に推奨されるディストリビューションモデルを示しています。ここで、 は暗号化されるリソース AWS アカウント と同じ 内に AWS KMS key 存在します。このため、 AWS KMS は Security Tooling アカウントに含まれるだけでなく、アプリケーションアカウントで使用されます。アプリケーションアカウントでは、アプリケーションリソースに固有のキーを管理する AWS KMS ために使用されます。キーポリシーを使用して、ローカルアプリケーションロールにキー使用権限を付与し、キー管理者への管理およびモニタリング権限を制限することで、職務の分離を実装できます。 

AWS CloudHSM

AWS CloudHSM は、 でマネージドハードウェアセキュリティモジュール (HSMs) を提供します AWS クラウド。これにより、アクセスを制御する FIPS 140-2 レベル 3 検証HSMs を使用して AWS 、 で独自の暗号化キーを生成して使用できます。を使用して AWS CloudHSM 、ウェブサーバーの SSL/TLS 処理をオフロードできます。これにより、Webサーバーの負担が軽減され、 AWS CloudHSM中のWebサーバーのプライベートキーが保存されるためセキュリティが強化されます。同様に、ネットワークアカウントの AWS CloudHSM インバウンド VPC に から HSM をデプロイしてプライベートキーを保存し、発行認証機関として機能する必要がある場合は証明書リクエストに署名できます。

AWS Secrets Manager

AWS Secrets Manager は、必要とする認証情報(secrets) を保護し、アプリケーションサービス、および IT リソースへアクセスするのに役立ちます。このサービスを使用すると、データベース認証情報、API キー、その他のシークレットをライフサイクルを通じて効率的にローテーション、管理、取得できます。コード内のハードコードされた認証情報 を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得できます。これは、シークレットがコード内に存在しなくなったため、コードを調べる人によってシークレットが侵害されないようにするのに役立ちます。さらに、Secrets Manager は、環境 (開発、本番前、本番) 間でアプリケーションを移動するのに役立ちます。コードを変更する代わりに、適切に名前が付けられ、参照されているシークレットが環境で使用可能であることを確認することができます。これにより、さまざまな環境でアプリケーションコードの一貫性と再利用性が促進されますが、コードのテスト後に必要な変更や人間による操作が少なくなります。

Secrets Manager を用いて、きめ細かい IAM ポリシーとリソースベースのポリシーを使用して、シークレットへのアクセスを管理できます。 AWS KMSを使用して、管理する暗号化キーを用いてシークレットを暗号化することで、シークレットを保護できます。Secrets Manager は、一元化された監査のための AWS ログ記録およびモニタリングサービスとも統合されます。

Secrets Manager は、 AWS KMS keys および データキーによるエンベロープ暗号化を使用して、各シークレット値を保護します。シークレットを作成するときは、 AWS アカウント および リージョンで任意の対称カスタマーマネージドキーを選択するか、Secrets Manager の AWS マネージドキーを使用できます。

ベストプラクティスとして、シークレットをモニタリングして変更を記録できます。これにより、予期しない使用や変更を調査できます。不要な変更はロールバックできます。Secrets Manager は現在、組織とアクティビティをモニタリング AWS のサービス できる 2 つの AWS CloudTrail と をサポートしています AWS Config。CloudTrail は、Secrets Manager コンソールからの呼び出しや Secrets Manager API へのコード呼び出しを含む、Secrets Manager のすべての API コールをイベントとしてキャプチャします。さらに、CloudTrail は、 にセキュリティやコンプライアンスに影響する可能性がある、 AWS アカウント または運用上の問題のトラブルシューティングに役立つ可能性がある、その他の関連 (非 API) イベントをキャプチャします。これには、特定のシークレットローテーションイベントやシークレットバージョンの削除が含まれます。 は、Secrets Manager のシークレットへの変更を追跡およびモニタリングすることで、検出コントロールを提供 AWS Config できます。これらの変更には、シークレットの説明、ローテーション設定、タグ、および KMS 暗号化キーやシークレットローテーションに使用される AWS Lambda 関数などの他の AWS ソースとの関係が含まれます。設定とコンプライアンスの変更の通知を受信する Amazon EventBridge を設定して AWS Config、通知または修復アクションのために特定のシークレットイベントをルーティングすることもできます。

AWS SRA では、Secrets Manager はアプリケーションアカウントに配置され、ローカルアプリケーションのユースケースをサポートし、使用状況に近いシークレットを管理します。ここでは、インスタンスプロファイルがアプリケーションアカウントの EC2 インスタンスにアタッチされます。次に、Secrets Manager で個別のシークレットを設定して、そのインスタンスプロファイルがシークレットを取得できるようにします。たとえば、適切な Active Directory または LDAP ドメインに参加し、Aurora データベースにアクセスできるようにします。Secrets Manager は Amazon RDS と統合され、Amazon RDS DB インスタンスまたはマルチ AZ DB クラスターを作成、変更、または復元するときにユーザー認証情報を管理します。これにより、キーの作成とローテーションを管理し、コード内のハードコードされた認証情報を Secrets Manager へのプログラムによる API コールに置き換えることができます。 

Amazon Cognito

Amazon Cognito を使用すると、ユーザーのサインアップ、サインイン、アクセスコントロールをウェブおよびモバイルアプリに迅速かつ効率的に追加できます。Amazon Cognito は数百万のユーザーにスケールし、Apple、Facebook、Google、Amazon などのソーシャル ID プロバイダー、および SAML 2.0 と OpenID Connect を介したエンタープライズ ID プロバイダーとのサインインをサポートします。Amazon Cognito の 2 つの主なコンポーネントは、ユーザープールと ID プールです。ユーザープールは、アプリケーションユーザーにサインアップとサインインのオプションを提供するユーザーディレクトリです。ID プールを使用すると、ユーザーに他の へのアクセスを許可できます AWS のサービス。ID プールとユーザープールは別々に使用することも、一緒に使用することもできます。一般的な使用シナリオについては、Amazon Cognito ドキュメントを参照してください。

Amazon Cognito は、ユーザーのサインアップとサインインのための組み込みのカスタマイズ可能な UI を提供します。Amazon Cognito 用の Android、iOS、JavaScript SDKs を使用して、アプリにユーザーのサインアップページとサインインページを追加できます。Amazon Cognito Sync は、アプリケーション関連のユーザーデータのデバイス間同期を可能にする AWS のサービス および クライアントライブラリです。

Amazon Cognito は、保管中のデータと転送中のデータの多要素認証と暗号化をサポートしています。Amazon Cognito ユーザープールは、アプリケーション内のユーザーアカウントへのアクセスを保護するのに役立つ高度なセキュリティ機能を提供します。これらの高度なセキュリティ機能は、リスクベースの適応認証を提供し、侵害された認証情報の使用から保護します。 

Amazon Verified Permissions

Amazon Verified Permissions は、構築するアプリケーションのスケーラブルなアクセス許可管理およびきめ細かな認可サービスです。開発者と管理者は、専用でセキュリティファーストのオープンソースポリシー言語である Cedar をロールと属性とともに使用して、よりきめ細かなコンテキスト対応のポリシーベースのアクセスコントロールを定義できます。開発者は、認可を外部化し、ポリシーの管理と管理を一元化することで、より安全なアプリケーションを迅速に構築できます。Verified Permissions には、スキーマ定義、ポリシーステートメントの文法、数百万のアクセス許可にまたがる自動推論が含まれているため、デフォルトの拒否と最小特権の原則を適用できます。このサービスには、認可の決定と作成者ポリシーのテストに役立つ評価シミュレーターツールも含まれています。これらの機能により、ゼロトラストオブジェクトをサポートするために、詳細できめ細かな認可モデルのデプロイが容易になります。Verified Permissions は、ポリシーストア内のアクセス許可を一元化し、開発者がこれらのアクセス許可を使用してアプリケーション内のユーザーアクションを承認するのに役立ちます。

API を使用してアプリケーションからサービスに接続し、ユーザーアクセスリクエストを承認できます。認可リクエストごとに、サービスは関連するポリシーを取得し、それらのポリシーを評価して、ユーザー、ロール、グループメンバーシップ、属性などのコンテキスト入力に基づいて、ユーザーがリソースに対してアクションを実行することを許可されているかどうかを判断します。Verified Permissions を設定して接続し、ポリシー管理および認可ログを送信できます AWS CloudTrail。ID ストアとして Amazon Cognito を使用する場合は、Verified Permissions と統合し、Amazon Cognito がアプリケーションの認可決定で返す ID トークンとアクセストークンを使用できます。Verified Permissions に Amazon Cognito トークンを提供します。これは、トークンに含まれる属性を使用してプリンシパルを表し、プリンシパルのエンタイトルメントを識別します。この統合の詳細については、ブログ AWS 記事「Simplifying fine-grained authorization with Amazon Verified Permissions and Amazon Cognito」を参照してください。 

Verified Permissions は、ポリシーベースのアクセスコントロール (PBAC) を定義するのに役立ちます。PBAC は、ポリシーとして表現されるアクセス許可を使用して、アプリケーション内のどのリソースにアクセスできるかを決定するアクセスコントロールモデルです。PBAC は、ロールベースのアクセスコントロール (RBAC) と属性ベースのアクセスコントロール (ABAC) を統合し、より強力で柔軟なアクセスコントロールモデルを実現します。PBAC の詳細と、Verified Permissions を使用して認可モデルを設計する方法については、 AWS ブログ記事「Amazon Verified Permissions を使用したアプリケーション開発におけるポリシーベースのアクセスコントロール」を参照してください。

AWS SRA では、Verified Permissions はアプリケーションアカウントにあり、Amazon Cognito との統合を通じてアプリケーションのアクセス許可管理をサポートします。

多層防御

アプリケーションアカウントは、 AWS を有効にするレイヤード防御プリンシパルを説明する機会を提供します。SRA で表されるシンプルなサンプルアプリケーションの中核をなす EC2 AWS インスタンスのセキュリティを考えてみましょう。多層防御で AWS のサービス 連携する方法を確認できます。このアプローチは、このガイドの前半の「組織全体に AWS セキュリティサービスを適用する」セクションで説明されているように、セキュリティサービスの構造図と一致しています AWS。