翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ワークロード OU — アプリケーションアカウント
| 簡単なアンケートを実施して |
次の図は、アプリケーションアカウントで設定されている AWS セキュリティサービス (およびアプリケーション自体) を示しています。
Application アカウントは、エンタープライズアプリケーションを実行および維持するためのプライマリインフラストラクチャとサービスをホストします。アプリケーションアカウントとワークロード OU は、いくつかの主要なセキュリティ目標を果たします。まず、アプリケーションごとに個別のアカウントを作成して、ワークロード間の境界と制御を提供し、役割、許可、データ、および暗号化キーが発生する問題を回避します。アプリケーションチームに、他のユーザーに影響を与えることなく、独自のインフラストラクチャを管理する幅広い権限を付与できる個別のアカウントコンテナを提供したいと考えています。次に、セキュリティ運用チームがセキュリティデータを監視および収集するメカニズムを提供して、保護のレイヤーを追加します。組織証跡とアカウントセキュリティサービス (Amazon GuardDuty、AWS Config、AWS Security Hub、Amazon EventBridge、AWS IAM Access Analyzer) をローカルにデプロイし、セキュリティチームが設定、監視します。最後に、企業が一元的に制御を設定できるようにします。アプリケーションアカウントは、適切なサービス権限、制約、およびガードレールを継承する Workloads OU のメンバーにして、より広範なセキュリティ構造に合わせます。
設計上の考慮事項
-
あなたの組織には複数のビジネスアプリケーションがあるでしょう。ワークロード OU は、実稼働環境と非実稼働環境の両方を含む、ビジネス固有のワークロードのほとんどを収容することを目的としています。これらのワークロードには、商用 off-the-shelf (COTS) アプリケーションと、社内で開発した独自のカスタムアプリケーションおよびデータサービスが混在している場合があります。さまざまなビジネスアプリケーションとその開発環境を整理するためのパターンはほとんどありません。1 つのパターンは、本番、ステージング、テスト、開発などの開発環境に基づいて複数の子 OU を用意し、それらの OU では異なるアプリケーションに関係する子の AWS アカウントを別々に使用することです。もう 1 つの一般的なパターンは、アプリケーションごとに別々の子 OU を用意し、個々の開発環境用に別々の子 AWS アカウントを使用することです。正確な OU とアカウント構造は、アプリケーションの設計とそれらのアプリケーションを管理するチームによって異なります。環境固有かアプリケーション固有かにかかわらず、実施したいセキュリティ制御を検討してください。これらの統制は、OU に SCP として実装する方が簡単だからです。ワークロード指向のOUの編成に関するその他の考慮事項については、AWSホワイトペーパー「複数のアカウントを使用してAWS環境を整理する」の「ワークロード指向のOUの整理」セクションを参照してください。
アプリケーション VPC
アプリケーションアカウントの仮想プライベートクラウド (VPC) には、インバウンドアクセス (モデリングしているシンプルなウェブサービスの場合) とアウトバウンドアクセス (アプリケーションニーズまたは AWS サービスニーズの場合) の両方が必要です。デフォルトでは、VPC 内のリソースは相互にルーティング可能です。2 つのプライベートサブネットがあります。1 つは EC2 インスタンス (アプリケーションレイヤー) をホストし、もう 1 つは Amazon Aurora (データベースレイヤー) 用です。アプリケーション層やデータベース層など、異なる層間のネットワークセグメンテーションは、インスタンスレベルでトラフィックを制限する VPC セキュリティグループを介して行われます。復元力のために、ワークロードは複数のアベイラビリティーゾーンにまたがり、ゾーンごとに 2 つのサブネットを使用します。
設計上の考慮事項
-
Traffic Mirroring を使用して、EC2 インスタンスの Elastic Network Interface からネットワークトラフィックをコピーできます。その後、 out-of-band トラフィックをセキュリティアプライアンスやモニタリングアプライアンスに送信して、コンテンツ検査、脅威モニタリング、トラブルシューティングを行うことができます。たとえば、VPC から出るトラフィック、またはソースが VPC 外にあるトラフィックを監視できます。この場合、VPC 内を通過するトラフィックを除くすべてのトラフィックをミラーリングし、単一のモニタリングアプライアンスに送信します。Amazon VPC フローログはミラートラフィックをキャプチャしません。通常、パケットヘッダーからのみ情報をキャプチャします。トラフィックミラーリングを使用すると、ペイロードを含む実際のトラフィックコンテンツを分析できるため、ネットワークトラフィックに関するより深い洞察が得られます。トラフィックミラーリングは、機密性の高いワークロードの一部として動作している可能性がある、または問題が発生した場合に詳細な診断が必要と予想される EC2 インスタンスの elastic network interface に対してのみ有効にします。
VPC エンドポイント
VPC endpoints は、スケーラビリティと信頼性だけでなく、セキュリティ制御の別のレイヤーを提供します。これらを使用して、アプリケーション VPC を他の AWS サービスに接続します。(アプリケーションアカウントでは、AWS SRA は AWS KMS、AWS Systems Manager、および Amazon S3 用の VPC エンドポイントを採用しています。) エンドポイントは仮想デバイスです。これらは水平にスケールされ、冗長で、可用性の高い VPC コンポーネントです。これにより、ネットワークトラフィックに可用性リスクや帯域幅の制約を課すことなく、VPC 内のインスタンスとサービス間の通信が可能になります。VPC エンドポイントを使用すると、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect PrivateLink 接続を必要とせずに、サポートされている AWS サービスや AWS が提供する VPC エンドポイントサービスにプライベートに VPC を接続できます。VPC 内のインスタンスは、他の AWS サービスと通信するためにパブリック IP アドレスを必要としません。VPC と他の AWS サービス間のトラフィックは Amazon ネットワークを離れません。
VPC エンドポイントを使用するもう 1 つの利点は、エンドポイントポリシーの設定を有効にすることです。VPC評価項目ポリシーは、評価項目の作成時または変更時に評価項目に加える国際機械技術者協会（IAM）のリソースポリシーです。エンドポイントの作成時に IAM ポリシーをアタッチしない場合、AWS はサービスへのフルアクセスを許可するデフォルトの IAM ポリシーをアタッチします。エンドポイントポリシーが IAM ポリシーやサービス固有のポリシー (S3 バケットポリシーなど) をオーバーライドしたり、置き換えたりすることはありません。これは、エンドポイントから指定されたサービスへのアクセスを制御するための別個の IAM ポリシーです。このようにして、AWS プリンシパルがリソースやサービスと通信できる制御層がもう1つ追加されます。
Amazon EC2
アプリケーションを構成する Amazon EC2
個別の VPC (アカウント境界のサブセットとして) を使用して、ワークロードセグメントごとにインフラストラクチャを分離します。サブネットを使用すると、単一の VPC 内で多階層ウェブアプリケーションの各階層 (ウェブサーバー、アプリケーションサーバーおよびデータベースサーバーなど) を隔離できます。インターネットからの直接アクセスを認めるべきでないインスタンスには、プライベートサブネットを使用します。インターネットゲートウェイを使用せずにプライベートサブネットから Amazon EC2 API を呼び出すには、AWS を使用します PrivateLink。セキュリティグループを使用してインスタンスへのアクセスを制限します。VPC フローログを使用して、インスタンスに到達するトラフィックを監視します。AWS Systems Manager の機能である Session Manager を使用すると、インバウンド SSH ポートを開いて SSH キーを管理する代わりに、インスタンスにリモートでアクセスできます。オペレーティングシステムとデータには、別々の Amazon Elastic Block Store (Amazon EBS) ボリュームを使用してください。作成する新しい EBS ボリュームとスナップショットコピーの暗号化を強制するように AWS アカウントを設定できます。
実装例:
AWS SRA コードライブラリには
Application Load Balancer
アプリケーションロードバランサーは
AWS Certificate Manager (ACM) はアプリケーションロードバランサーとネイティブに統合され、AWS SRA は ACM を使用して必要な X.509 (TLS サーバー) パブリック証明書を生成および管理します。Application Load Balancer セキュリティポリシーを通して、フロントエンド接続に TLS 1.2 と強力な暗号を適用できます。詳細については、「Elastic Load Balancing ドキュメント」を参照してください。
設計上の考慮事項
-
Application Load Balancer でプライベート TLS 証明書を必要とする内部アプリケーションなどの一般的なシナリオでは、このアカウント内の ACM を使用してプライベート証明書を生成できます。AWS Private CAAWS SRA では、ACM ルートプライベート CA は Security Tooling アカウントでホストされ、Security Tooling アカウントセクションで前述したように、AWS 組織全体または特定の AWS アカウントと共有してエンドエンティティ証明書を発行できます。
-
パブリック証明書の場合は、ACM を使用して証明書を生成し、自動ローテーションを含めて管理できます。または、SSL/TLS ツールを使用して独自の証明書を生成して証明書署名リクエスト (CSR) を作成し、認証局 (CA) に CSR の署名を得て証明書を作成し、証明書を ACM にインポートするか、証明書を IAM にアップロードして Application Load Balancer で使用することもできます。証明書をACMにインポートする場合は、証明書の有効期限を監視し、有効期限が切れる前に更新する必要があります。
-
追加の防御レイヤーとして、AWS WAF ポリシーをデプロイしてApplication Load Balancer を保護できます。エッジポリシー、アプリケーションポリシー、さらにはプライベートまたは内部ポリシー強制レイヤーさえあれば、通信要求の可視性が高まり、統一されたポリシー強制が提供されます。詳細については、ブログ記事「AWS WAF 用 AWS マネージドルールを使用して多層防御をデプロイする
」を参照してください。
AWS Private CA
AWS Private Certificate Authority(AWS Private CA) は、Application Load Balancer で使用するプライベート証明書を生成するためにアプリケーションアカウントで使用されます。アプリケーションロードバランサーでは、TLS 経由で安全なコンテンツを提供するのが一般的なシナリオです。これには、TLS 証明書をApplication Load Balancer にインストールする必要があります。完全に内部向けのアプリケーションでは、プライベート TLS 証明書が安全なチャネルを提供できます。
AWS SRA では、セキュリティツールアカウントでホストされ、AWS AWS Private CA RAM を使用してアプリケーションアカウントに共有されます。これにより、アプリケーションアカウントの開発者は共有プライベート CA に証明書をリクエストできます。組織全体または AWS アカウント間で CA を共有することで、すべての AWS アカウントで重複する CA を作成および管理するコストと複雑さを軽減できます。ACM を使用して共有 CA からプライベート証明書を発行すると、証明書はリクエスト元のアカウントでローカルに生成され、ACM はライフサイクル全体の管理と更新を行います。
Amazon Inspector
AWS SRA は Amazon Inspector を使用して、Amazon
Amazon Inspector は、このアカウントの EC2 インスタンスに脆弱性管理サービスを提供するため、アプリケーションアカウントに配置されます。さらに、Amazon Inspector は EC2 インスタンスとの間で送受信される不要なネットワークパスについても報告します。
メンバーアカウントの Amazon Inspector は、委任された管理者アカウントによって一元管理されます。AWS SRA では、セキュリティツールアカウントは委任された管理者アカウントです。委任された管理者アカウントは、組織のメンバーの調査結果データや特定の設定を管理できます。これには、すべてのメンバーアカウントの集計結果の詳細の表示、メンバーアカウントのスキャンの有効化または無効化、AWS 組織内のスキャンされたリソースの確認が含まれます。
設計上の考慮事項
-
AWS Systems Manager の機能である Patch Manager を使用してオンデマンドパッチをトリガーし、Amazon Inspector のゼロデイまたはその他の重大なセキュリティ脆弱性を修復できます。Patch Manager を使用すると、通常のパッチ適用スケジュールを待たずにこれらの脆弱性にパッチを適用できます。修復は、Systems Manager 自動化ランブックを使用して実行されます。詳細については、2 部構成のブログシリーズ「Amazon Inspector と AWS Systems Manager を使用して AWS の脆弱性管理と修復を自動化する
」を参照してください。
Amazon Systems Manager
AWS Systems Manager
これらの一般的な自動化機能に加えて、Systems Manager は、予防、detective な、および応答性の高いセキュリティ機能を多数サポートしています。AWS Systems Manager エージェント (SSM エージェント) は、EC2 インスタンス、オンプレミスサーバー、または仮想マシン (VM) にインストールして設定できる Amazon ソフトウェアです。SSM Agent により、Systems Manager がこれらのリソースを更新、管理、および設定できるようにします。Systems Manager は、管理対象インスタンスをスキャンし、パッチ、設定、カスタムポリシーで検出された違反を報告 (または是正措置) することで、セキュリティとコンプライアンスを維持するのに役立ちます。
AWS SRA は Systems Manager の機能であるセッションマネージャーを使用して、インタラクティブなブラウザベースのシェルと CLI エクスペリエンスを提供します。これにより、インバウンドポートを開いたり、baston ホストを維持したり、SSH キーを管理したりすることなく、安全で監査可能なインスタンス管理が提供されます。AWS SRA は Systems Manager の機能である Patch Manager を使用して、オペレーティングシステムとアプリケーションの両方の EC2 インスタンスにパッチを適用します。
AWS SRA は、Systems Manager の機能である自動化も使用して、Amazon EC2 インスタンスやその他の AWS リソースの一般的なメンテナンスとデプロイタスクを簡素化します。オートメーションは、1 つ以上のノードの状態を変更 (承認されたオートメーションを使用) したり、スケジュールに従ってノードの状態を管理するなどの一般的な IT タスクを簡略化できます。Systems Manager には、タグを使用したインスタンスの大規模なグループのターゲットに役立つ機能や定義する制限に応じた変更を行うために役立つ速度制御といった機能が含まれます。Automation は、golden Amazon マシンイメージ (AMI) の作成や到達不可能な EC2 インスタンスの復元などの複雑なタスクを簡素化する、ワンクリックAutomation を提供します。さらに、IAM ロールに特定の機能を実行するためのアクセス権限を IAM ロールに付与し、それらのロールに直接アクセス権限を与えることなく、運用上のセキュリティを強化できます。たとえば、パッチアップデート後に特定の EC2 インスタンスを再起動する権限を IAM ロールに付与したいが、そのロールには直接権限を付与したくない場合、代わりに自動化ランブックを作成し、そのロールにランブックのみを実行する権限を与えることができます。
設計上の考慮事項
-
Systems Manager の正常な機能は、EC2 インスタンスメタデータに左右されます。Systems Manager は、インスタンスメタデータサービスのバージョン 1 またはバージョン 2（IMDSv1 および IMDSv2）を使用してインスタンスメタデータにアクセスできます。
-
SSM エージェントは、Amazon EC2 メッセージ、Systems Manager、Amazon S3 などのさまざまな AWS サービスおよびリソースと通信する必要があります。この通信を実現するには、サブネットにアウトバウンドインターネット接続または適切な VPC エンドポイントのプロビジョニングが必要です。AWS SRA は SSM エージェントの VPC エンドポイントを使用して、さまざまな AWS サービスへのプライベートネットワークパスを確立します。
-
オートメーションを使用すると、組織内でベストプラクティスを共有できます。Runbook でリソース管理のベストプラクティスを作成し、その Runbook を AWS リージョンやグループ間で共有できます。Runbook パラメータの許容値を制限することもできます。このようなユースケースでは、セキュリティツールや共有サービスなどの中央アカウントで自動化ランブックを作成し、AWS 組織の他のメンバーと共有する必要がある場合があります。一般的なユースケースには、パッチやセキュリティアップデートを一元的に実装する機能、VPC 設定や S3 バケットポリシーのドリフトを修正する機能、EC2 インスタンスを大規模に管理する機能などがあります。実装の詳細については、Systems Manager のマニュアルを参照してください。
Amazon Aurora
AWS SRA では、Amazon Aurora
設計上の考慮事項
-
多くのデータベースサービスと同様に、Aurora のセキュリティは 3 つのレベルで管理されます。AuroraDB クラスターおよび DB インスタンス上でAmazon Relational Database Service（Amazon RDS）管理アクションを実行できるユーザーを制御するには、IAMを使用します VPC 内の Aurora DB クラスタのクラスタエンドポイントと DB インスタンスのポートへの接続を開くことができるデバイスと EC2 インスタンスを制御するには、VPC セキュリティグループを使用します。Aurora DB クラスターのログインとアクセス権限を認証するには、MySQL または PostgreSQL のスタンドアロン DB インスタンスと同じ方法を使用するか、Aurora MySQL 互換エディションの IAM データベース認証を使用します。この後者のアプローチでは、IAM ロールと認証トークンを使用して、Aurora MySQL 互換 DB クラスターに対して認証を行います。
Amazon S3
Amazon S3
AWS KMS
AWS SRA は、KMS キーが暗号化対象リソースと同じ AWS アカウント内に存在する、キー管理の推奨配布モデルを示しています。このため、AWS KMS は Security Tooling アカウントに含まれるだけでなく、アプリケーションアカウントでも使用されます。アプリケーションアカウントでは、AWS KMS を使用してアプリケーションリソース固有のキーを管理します。キーポリシーを使用してローカルのアプリケーションロールにキーの使用権限を付与し、管理権限とモニタリング権限をキー管理者に限定することで、職務の分離を実現できます。
設計上の考慮事項
-
分散型モデルでは、AWS KMS キー管理の責任はアプリケーションチームにあります。ただし、次のような重要な暗号化イベントのガバナンスと監視は、中央セキュリティチームが担当する場合があります。
-
KMS キーにインポートされたキーマテリアルの有効期限が近づいています。
-
KMS キーのキーマテリアルが自動的にローテーションされました。
-
KMS キーが削除されました。
-
復号化に失敗する確率は高い。
-
AWS CloudHSM
AWS CloudHSM
設計上の考慮事項
-
FIPS 140-2 レベル 3 に対する厳しい要件がある場合は、ネイティブの KMS キーストアを使用する代わりに CloudHSM クラスターをカスタムキーストアとして使用するように AWS KMS を設定することもできます。そうすることで、データを暗号化する AWS KMS と AWS サービスを統合できるというメリットがありますが、KMS キーを保護する HSM の責任も負うことになります。これにより、管理下にあるシングルテナント HSM と、AWS KMS の使いやすさと統合が組み合わされます。CloudHSM インフラストラクチャを管理するには、公開鍵インフラストラクチャ (PKI) を採用し、HSM の管理経験のあるチームを編成する必要があります。
AWS Secrets Manager
AWS Secrets Manager
Secrets Manager を用いて、きめ細かい IAM ポリシーとリソースベースのポリシーを使用して、シークレットへのアクセスを管理できます。AWS KMS を使用して管理する暗号化キーでシークレットを暗号化することで、シークレットを保護できます。Secrets Manager は、AWS Sのロギングおよびモニタリングサービスと統合されているため、一元的な監査が可能です。
Secrets Manager は、AWS KMS キーとデータキーによるエンベロープ暗号化を使用して、各シークレット値を保護します。シークレットを作成するときは、AWS Sアカウントとリージョンで任意の対称カスタマー管理キーを選択するか、Secrets Manager のAWS 管理キーを使用できます。
ベストプラクティスとして、シークレットを監視して変更を記録することができます。これにより、予期しない使用や変更を確実に調査できます。不要な変更はロールバックできます。Secrets Manager は現在、組織とアクティビティを監視できるようにする2つのAWSサービス、 CloudTrail AWSとAWS Configをサポートしています。 CloudTrail Secrets Manager コンソールからの呼び出しやSecrets Manager API へのコード呼び出しを含め、Secrets Manager のすべての API 呼び出しをイベントとしてキャプチャします。さらに、AWS アカウントにセキュリティやコンプライアンスに影響を与える可能性のある、または運用上の問題のトラブルシューティングに役立つ可能性のある、その他の関連する (API 以外の) CloudTrail イベントをキャプチャします。これらには、特定のシークレットのローテーションイベントやシークレットバージョンの削除が含まれます。AWS Config では、Secrets Manager のシークレットの変更を追跡およびモニタリングすることで、探偵による制御を行うことができます。これらの変更には、シークレットの説明、ローテーション設定、タグ、KMS暗号化キーやシークレットローテーションに使用されるAWS Lambda関数などの他のAWSソースとの関係が含まれます。また EventBridge、AWS Config から設定とコンプライアンスの変更通知を受け取る Amazon を設定して、特定のシークレットイベントを通知または修復アクションのためにルーティングすることもできます。
AWS SRA では、Secrets Manager はアプリケーションアカウント内に配置され、ローカルアプリケーションのユースケースをサポートし、その使用状況に近いシークレットを管理します。ここでは、インスタンスプロファイルがアプリケーションアカウントの EC2 インスタンスにアタッチされます。次に、Secrets Manager で個別のシークレットを設定して、そのインスタンスプロファイルがシークレットを取得できるようにします。たとえば、適切な Active Directory または LDAP ドメインに参加し、Aurora データベースにアクセスできるようにします。Secrets Manager は Amazon RDS と統合して、Amazon RDS DB インスタンスまたはマルチ AZ DB クラスターを作成、変更、または復元する際のユーザー認証情報を管理します。これにより、キーの作成とローテーションを管理しやすくなり、コード内のハードコーディングされた認証情報を Secrets Manager へのプログラムによる API 呼び出しに置き換えることができます。
設計上の考慮事項
-
一般に、シークレットが使用される場所に最も近いアカウントで Secrets Manager を設定および管理します。このアプローチは、ユースケースに関するローカルな知識を活用し、アプリケーション開発チームにスピードと柔軟性を提供します。厳重に管理された情報で、追加の制御レイヤーが適切である可能性がある場合は、Security ToolingアカウントのSecrets Managerによってシークレットを一元管理できます。
Amazon Cognito
Amazon Cognito
Amazon Cognito には、ユーザーのサインアップとサインインのためのカスタマイズ可能な UI が組み込まれています。Amazon Cognito 用の Android、iOS、および JavaScript SDK を使用して、ユーザーのサインアップページとサインインページをアプリケーションに追加できます。Amazon Cognito Sync は、アプリケーション関連のユーザーデータのデバイス間の同期を可能にする AWS サービスおよびクライアントライブラリです。
Amazon Cognito は、保存中のデータと転送中のデータの多要素認証と暗号化をサポートしています。Amazon Cognito ユーザープールは、アプリケーションのアカウントへのアクセスを保護するのに役立つ高度なセキュリティ機能を提供します。これらの高度なセキュリティ機能により、リスクベースの適応型認証が可能になり、認証情報の漏洩を防ぐことができます。
設計上の考慮事項
-
AWS Lambda 関数を作成し、ユーザーのサインアップ、確認、AWS Lambda トリガーによるサインイン (認証) などのユーザープール操作中にその関数をトリガーできます。認証チャレンジの追加、ユーザーの移行、検証メッセージのカスタマイズを行うことができます。一般的な操作とユーザーフローについては、Amazon Cognito ドキュメントを参照してください。Amazon Cognito は Lambda 関数を同期的に呼び出します。
-
Amazon Cognito ユーザープールを使用して、小規模なマルチテナントアプリケーションを保護できます。マルチテナント設計の一般的な使用例は、アプリケーションの複数のバージョンのテストをサポートするためにワークロードを実行することです。マルチテナント設計は異なるデータセットを持つ単一のアプリケーションのテストにも役立ち、これはクラスターリソースを最大限に活用することを可能にします。ただし、テナントの数と予想されるボリュームが、関連する Amazon Cognito サービスクォータと一致していることを確認してください。これらのクォータは、アプリケーション内のすべてのテナント間で共有されます。
Amazon Verified Permissions
Amazon Verified Permissions
API を介してアプリケーションをサービスに接続し、ユーザーアクセスリクエストを承認できます。認可リクエストごとに、サービスは関連するポリシーを取得して評価し、ユーザー、ロール、グループメンバーシップ、属性などのコンテキスト入力に基づいて、ユーザーがリソースに対してアクションを実行できるかどうかを判断します。検証済みアクセス権限を設定して接続し、ポリシー管理ログと認証ログを AWS に送信できます CloudTrail。Amazon Cognito をアイデンティティストアとして使用する場合は、検証済みアクセス権限と統合して、Amazon Cognito が返す ID とアクセストークンをアプリケーションの承認決定に使用できます。Amazon Cognito トークンを検証済みアクセス権限に渡します。認証済みアクセス権限では、トークンに含まれる属性を使用してプリンシパルを表し、プリンシパルの資格を識別します。この統合の詳細については、AWS ブログ記事「Amazon 検証済みアクセス権限と Amazon Cognito によるきめ細かい認証の簡略化
検証済みアクセス権限は、ポリシーベースのアクセス制御 (PBAC) を定義するのに役立ちます。PBAC は、ポリシーとして表現される権限を使用して、アプリケーション内のどのリソースに誰がアクセスできるかを決定するアクセス制御モデルです。PBAC はロールベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) を統合し、より強力で柔軟なアクセス制御モデルを実現します。PBAC の詳細と、検証済みアクセス権限を使用して認証モデルを設計する方法については、AWS ブログ記事「Amazon 検証済みアクセス権限によるアプリケーション開発におけるポリシーベースのアクセス制御
AWS SRA では、検証済みアクセス権限はアプリケーションアカウントにあり、Amazon Cognito との統合によるアプリケーションの権限管理をサポートします。
多層防御
アプリケーションアカウントは、AWS で実現可能な多層防御プリンシパルを説明する機会を提供します。AWS SRA に示されている簡単なサンプルアプリケーションのコアを構成する EC2 インスタンスのセキュリティを考えてみると、多層防御で AWS のサービスが連携する方法がわかります。このアプローチは、このガイドの前半の「AWS 組織全体にセキュリティサービスを適用する」セクションで説明した AWS セキュリティサービスの構造的見方と一致しています。
-
最も内側のレイヤーは EC2 インスタンスです。前述のように、EC2 インスタンスには、デフォルトまたはオプションとして多くのネイティブセキュリティ機能が含まれています。例としては、IMDSv2、Nitro システム
、Amazon EBS ストレージ暗号化などがあります。 -
2 番目の保護レイヤーは、EC2 インスタンスで実行されるオペレーティングシステムとソフトウェアに焦点を当てています。Amazon Inspector
や AWS Systems Manager などのサービスにより、これらの設定を監視、報告し、修正措置を講じることができます。Inspectorはソフトウェアの脆弱性を監視し 、Systems Manager はマネージドインスタンスのパッチと構成ステータスをスキャンし、報告して指定した是正措置を取ることにより、セキュリティとコンプライアンスの維持に役立ちます。 -
インスタンス、およびこれらのインスタンスで実行されるソフトウェアは、AWS ネットワークインフラストラクチャと連携します。Amazon VPC のセキュリティ機能を使用するだけでなく、AWS SRA は VPC エンドポイントを利用して VPC とサポートされている AWS サービス間のプライベート接続を提供し、ネットワークの境界にアクセスポリシーを設定するメカニズムを提供します。
-
EC2 インスタンス、ソフトウェア、ネットワーク、IAM のロールとリソースのアクティビティと設定は、AWS セキュリティハブ、Amazon、AWS、AWS Config、AWS IAM アクセスアナライザー GuardDuty、Amazon Macie などの AWS アカウントに焦点を当てたサービスによってさらに監視されます。 CloudTrail
-
最後に、アプリケーションアカウント以外にも、AWS RAM は他のアカウントと共有するリソースを制御するのに役立ち、IAM サービスコントロールポリシーは AWS 組織全体で一貫したアクセス権限を適用するのに役立ちます。
