翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
エッジのセキュリティ
では AWS クラウド、セキュリティが最優先事項です。組織がクラウドのスケーラビリティと柔軟性を採用するにつれて、 はセキュリティ、アイデンティティ、コンプライアンスを主要なビジネス要素として採用する AWS のに役立ちます。 は、セキュリティをコアインフラストラクチャ AWS に統合し、独自のクラウドセキュリティ要件を満たすのに役立つサービスを提供します。アーキテクチャの範囲を に拡張すると AWS クラウド、Local Zones や Outposts などのインフラストラクチャを に統合する利点があります AWS リージョン。この統合により AWS 、 はコアセキュリティサービスの選択されたグループをエッジに拡張できます。
セキュリティは、 AWS お客様とお客様の間の責任共有です。AWS 責任共有モデルは
-
クラウドのセキュリティ – AWS は、 AWS のサービス で実行されるインフラストラクチャを保護する責任を担います AWS クラウド。 AWS また、 は、お客様が安全に使用できるサービスも提供します。サードパーティーの監査者は、AWS コンプライアンスプログラム
の一環として、 AWS セキュリティの有効性を定期的にテストおよび検証します。 -
クラウド内のセキュリティ – お客様の責任は、使用する によって決まり AWS のサービス ます。また、お客様は、お客様のデータの機密性、企業の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
データ保護
責任 AWS 共有モデルは、 AWS Outposts および でのデータ保護に適用されます AWS Local Zones。このモデルで説明されているように、 AWS は AWS クラウド (クラウドのセキュリティ) を実行するグローバルインフラストラクチャを保護する責任があります。このインフラストラクチャ (クラウドのセキュリティ) でホストされているコンテンツの制御を維持するのはお客様の責任です。このコンテンツには、 AWS のサービス 使用する のセキュリティ設定および管理タスクが含まれます。
データ保護の目的で、 AWS Identity and Access Management (IAM) または を使用して AWS アカウント 認証情報を保護し、個々のユーザーを設定することをお勧めしますAWS IAM Identity Center。これにより、各ユーザーに各自の職務を果たすために必要なアクセス許可のみが付与されます。
保管中の暗号化
EBS ボリュームでの暗号化
では AWS Outposts、すべてのデータは保管時に暗号化されます。キーマテリアルは、外部キーである Nitro Security Key (NSK) でラップされ、リムーバブルデバイスに保存されます。NSK は、Outpost ラック上のデータを復号化するために必要です。EBS ボリュームとスナップショットに Amazon EBS 暗号化を使用できます。Amazon EBS 暗号化ではAWS Key Management Service 、 (AWS KMS) と KMS キーを使用します。
Local Zones の場合、アカウントで暗号化が有効になっていない限り、 すべての EBS ボリュームはすべての Local Zones でデフォルトで暗号化されます。ただし、AWS Local Zones よくある質問
Amazon S3 on Outposts での暗号化
デフォルトでは、Amazon S3 on Outposts に保存されるすべてのデータは、Amazon S3 マネージド暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。オプションで、ユーザーが用意した暗号化キーによるサーバー側の暗号化 (SSE-C) を使用できます。SSE-C を使用するには、オブジェクト API リクエストの一部として暗号化キーを指定します。サーバー側の暗号化では、オブジェクトのメタデータではなく、オブジェクトデータのみが暗号化されます。
注記
Amazon S3 on Outposts は、KMS キーによるサーバー側の暗号化 (SSE-KMS) をサポートしていません。
転送中の暗号化
の場合 AWS Outposts、サービスリンクは Outposts サーバーと選択した AWS リージョン (またはホームリージョン) との間の必要な接続であり、Outpost の管理と との間のトラフィックの交換を可能にします AWS リージョン。サービスリンクは、 AWS マネージド VPN を使用してホームリージョンと通信します。内の各ホストは、コントロールプレーントラフィックと VPC トラフィックを分割するための一連の VPN トンネル AWS Outposts を作成します。のサービスリンク接続 (インターネットまたは AWS Direct Connect) に応じて AWS Outposts、これらのトンネルでは、サービスリンクの上にオーバーレイを作成するためにファイアウォールポートを開く必要があります。とサービスリンクのセキュリティに関する詳細な技術情報については、 AWS Outposts ドキュメントの AWS Outposts 「サービスリンクを介した接続」と「インフラストラクチャセキュリティ AWS Outposts」を参照してください。
AWS Outposts サービスリンクは、次の図に示すように AWS リージョン、親へのコントロールプレーンとデータプレーンの接続を確立する暗号化されたトンネルを作成します。
各 AWS Outposts ホスト (コンピューティングとストレージ) は、親リージョンと通信するために、よく知られている TCP ポートと UDP ポートを介してこれらの暗号化されたトンネルを必要とします。次の表は、UDP プロトコルと TCP プロトコルの送信元ポートと送信先ポートとアドレスを示しています。
[プロトコル] |
ソースポート |
送信元アドレス |
送信先ポート |
送信先アドレス |
|---|---|---|---|---|
UDP |
443 |
AWS Outposts サービスリンク /26 |
443 |
AWS Outposts リージョンのパブリックルートまたはアンカー VPC CIDR |
TCP |
1025-65535 |
AWS Outposts サービスリンク /26 |
443 |
AWS Outposts リージョンのパブリックルートまたはアンカー VPC CIDR |
ローカルゾーンは、Amazon の冗長かつ高帯域幅のグローバルプライベートバックボーンを介して親リージョンにも接続されます。この接続により、ローカルゾーンで実行されているアプリケーションに、他の への高速、セキュア、シームレスなアクセスが可能になります AWS のサービス。ローカルゾーンが AWS グローバルインフラストラクチャの一部である限り、 AWS グローバルネットワークを通過するすべてのデータは、 AWS 保護された施設を離れる前に物理レイヤーで自動的に暗号化されます。オンプレミスロケーションと AWS Direct Connect PoPs 間で転送中のデータを暗号化してローカルゾーンにアクセスする特定の要件がある場合は、オンプレミスルーターまたはスイッチと AWS Direct Connect エンドポイントの間で MAC セキュリティ (MACsec) を有効にできます。詳細については、 AWS ブログ記事AWS Direct Connect 「接続への MACsec セキュリティの追加
データの削除
で EC2 インスタンスを停止または終了すると AWS Outposts、そのインスタンスに割り当てられたメモリは、新しいインスタンスに割り当てられる前にハイパーバイザーによってスクラブ (ゼロに設定) され、ストレージのすべてのブロックがリセットされます。Outpost ハードウェアからデータを削除するには、特殊なハードウェアを使用します。NSK は、次の写真に示されている小さなデバイスで、Outpost 内のすべてのコンピューティングまたはストレージユニットの前面にアタッチされます。これは、データセンターやコロケーションサイトからデータが公開されないようにするメカニズムを提供するように設計されています。Outpost デバイスのデータは、デバイスの暗号化に使用されるキーマテリアルをラップし、ラップされたマテリアルを NSK に保存することで保護されます。Outpost ホストを返すときは、NSK を破壊するチップの小さなネジを回して NSK を破壊し、物理的にチップを破壊します。NSK を破棄すると、Outpost のデータを暗号化的にシュレッダーにかけます。
Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を認証 (サインイン) し、誰に AWS Outposts リソースの使用を許可する (アクセス許可を付与する) かを制御します。をお持ちの場合は AWS アカウント、追加料金なしで IAM を使用できます。
次の表に、 で使用できる IAM 機能を示します AWS Outposts。
IAM の機能 |
AWS Outposts のサポート |
|---|---|
アイデンティティベースポリシー |
はい |
リソースベースのポリシー |
はい* |
ポリシーアクション |
はい |
ポリシーリソース |
はい |
ポリシー条件キー (サービス固有) |
あり |
アクセスコントロールリスト (ACL) |
なし |
属性ベースのアクセスコントロール (ABAC) (ポリシーのタグ) |
あり |
一時的な認証情報 |
はい |
プリンシパル権限 |
はい |
サービスロール |
いいえ |
サービスリンクロール |
あり |
* Amazon S3 on Outposts は、IAM アイデンティティベースのポリシーに加えて、バケットポリシーとアクセスポイントポリシーの両方をサポートしています。これらは、Amazon S3 on Outposts リソースにアタッチされたリソースベースのポリシーです。
これらの機能が でサポートされる方法の詳細については AWS Outposts、 AWS Outposts ユーザーガイドを参照してください。
インフラストラクチャセキュリティ
インフラストラクチャ保護は、情報セキュリティプログラムの重要な部分です。これにより、ワークロードシステムとサービスは、意図しない不正アクセスや潜在的な脆弱性から保護されます。たとえば、信頼境界 (ネットワークとアカウントの境界など)、システムセキュリティの設定とメンテナンス (強化、最小化、パッチ適用など)、オペレーティングシステムの認証と認可 (ユーザー、キー、アクセスレベルなど)、その他の適切なポリシー適用ポイント (ウェブアプリケーションファイアウォールや API ゲートウェイなど) を定義します。
AWS は、以下のセクションで説明するように、インフラストラクチャ保護に対するさまざまなアプローチを提供します。
ネットワークの保護
ユーザーはワークフォースまたは顧客の一部であり、どこにでも配置できます。このため、ネットワークにアクセスできるすべてのユーザーを信頼することはできません。すべてのレイヤーにセキュリティを適用する原則に従う場合は、ゼロトラスト
-
ネットワークレイヤーを作成します。レイヤードネットワークは、類似したネットワークコンポーネントを論理的にグループ化するのに役立ちます。また、不正なネットワークアクセスの影響の潜在的な範囲を縮小します。
-
トラフィックレイヤーを制御します。インバウンドトラフィックとアウトバウンドトラフィックの両方にdefense-in-depthアプローチで複数のコントロールを適用します。これには、セキュリティグループ (ステートフル検査ファイアウォール)、ネットワーク ACLs、サブネット、ルートテーブルの使用が含まれます。
-
検査と保護を実装します。各レイヤーでトラフィックを検査し、フィルタリングします。Network Access Analyzer を使用して、VPC 設定で意図しないアクセスの可能性を調べることができます。ネットワークアクセス要件を指定し、それらを満たしていない潜在的なネットワークパスを特定できます。
コンピューティングリソースの保護
コンピューティングリソースには、EC2 インスタンス、コンテナ、 AWS Lambda 関数、データベースサービス、IoT デバイスなどが含まれます。コンピューティングリソースタイプごとに異なるセキュリティアプローチが必要です。ただし、これらのリソースは、多層防御、脆弱性管理、攻撃対象領域の削減、設定と運用の自動化、遠くでのアクションの実行など、考慮すべき一般的な戦略を共有します。
主要なサービスのコンピューティングリソースを保護するための一般的なガイダンスを次に示します。
-
脆弱性管理プログラムを作成して維持します。EC2 インスタンス、Amazon Elastic Container Service (Amazon ECS) コンテナ、Amazon Elastic Kubernetes Service (Amazon EKS) ワークロードなどのリソースを定期的にスキャンしてパッチを適用します。
-
コンピューティング保護を自動化します。脆弱性管理、攻撃対象領域の削減、リソースの管理など、保護コンピューティングメカニズムを自動化します。この自動化により、ワークロードの他の側面を保護するために使用できる時間が解放され、人為的ミスのリスクが軽減されます。
-
アタックサーフェスを減らします。オペレーティングシステムを強化し、使用するコンポーネント、ライブラリ、外部で使用可能なサービスを最小限に抑えることで、意図しないアクセスへの露出を減らします。
さらに、 AWS のサービス 使用する ごとに、サービスドキュメントで特定のセキュリティ推奨事項を確認してください。
インターネットアクセス
AWS Outposts と Local Zones の両方が、ワークロードがインターネットとの間でアクセスできるようにするアーキテクチャパターンを提供します。これらのパターンを使用する場合は、外部の Git リポジトリへのパッチ適用、更新、アクセスなどに使用する場合のみ AWS、リージョンからのインターネット消費を有効なオプションと見なしてください。このアーキテクチャパターンでは、一元化されたインバウンド検査と一元化されたインターネット出力の概念が適用されます。これらのアクセスパターンは AWS Transit Gateway、、NAT ゲートウェイ、ネットワークファイアウォール、およびその他のコンポーネントを使用しますが AWS リージョン、リージョンとエッジ間のデータパスを介して AWS Outposts または Local Zones に接続されます。
Local Zones は、ネットワーク境界グループと呼ばれるネットワーク構造を採用します AWS リージョン。この境界グループは、これらの一意のグループのパブリック IP アドレスを AWS アドバタイズします。ネットワーク境界グループは、アベイラビリティーゾーン、ローカルゾーン、または Wavelength Zone で構成されます。ネットワーク境界グループで使用するパブリック IP アドレスのプールを明示的に割り当てることができます。ネットワーク境界グループを使用して、Elastic IP アドレスをグループから提供できるようにすることで、インターネットゲートウェイをローカルゾーンに拡張できます。このオプションでは、ローカルゾーンで利用可能なコアサービスを補完するために、他のコンポーネントをデプロイする必要があります。これらのコンポーネントは ISVs から取得され、 AWS ブログ記事 Hybrid inspection architectures with で説明されているように、Local Zone で検査 AWS Local Zones
で AWS Outposts、ローカルゲートウェイ (LGW) を使用してネットワークからインターネットにアクセスする場合は、 AWS Outposts サブネットに関連付けられているカスタムルートテーブルを変更する必要があります。ルートテーブルには、次のホップとして LGW を使用するデフォルトのルートエントリ (0.0.0.0/0) が必要です。お客様は、ファイアウォールや侵入防止システム、侵入検知システム (IPS/IDS) などの境界防御など、残りのセキュリティコントロールをローカルネットワークに実装する責任があります。これは、ユーザーとクラウドプロバイダーのセキュリティ職務を分割する 責任共有モデルと一致しています。
親を介したインターネットアクセス AWS リージョン
このオプションでは、Outpost のワークロードは、サービスリンクと親のインターネットゲートウェイを介してインターネットにアクセスします AWS リージョン。インターネットへのアウトバウンドトラフィックは、VPC でインスタンス化された NAT ゲートウェイを介してルーティングできます。イングレストラフィックとエグレストラフィックのセキュリティを強化するには、 で AWS WAF AWS Shieldや Amazon CloudFront などの AWS セキュリティサービスを使用できます AWS リージョン。
次の図は、 AWS Outposts インスタンス内のワークロードと親を通過するインターネット間のトラフィックを示しています AWS リージョン。
ローカルデータセンターのネットワーク経由のインターネットアクセス
このオプションでは、Outpost のワークロードはローカルデータセンターを介してインターネットにアクセスします。インターネットにアクセスするワークロードトラフィックは、ローカルインターネットのプレゼンスポイントを通過し、ローカルに出力されます。この場合、ローカルデータセンターのネットワークセキュリティインフラストラクチャがワークロードトラフィックの保護を担当します AWS Outposts 。
次の図は、 AWS Outposts サブネット内のワークロードと、データセンターを通過するインターネット間のトラフィックを示しています。
インフラストラクチャガバナンス
ワークロードが AWS リージョン、ローカルゾーン、または Outpost にデプロイされているかどうかにかかわらず、 インフラストラクチャガバナンス AWS Control Tower に を使用できます。 は、規範的なベストプラクティスに従って、 AWS マルチアカウント環境を設定および管理するための簡単な方法 AWS Control Tower を提供します。 は AWS Organizations、 や IAM アイデンティティセンター (すべての統合サービスを参照) など AWS のサービス、他のいくつかの の機能 AWS Control Tower を調整し AWS Service Catalogて、1 時間以内にランディングゾーンを構築します。リソースは、ユーザーに代わって設定および管理されます。
AWS Control Tower は、リージョン、ローカルゾーン (低レイテンシーの拡張機能)、Outposts (オンプレミスインフラストラクチャ) など、すべての AWS 環境にわたって統一されたガバナンスを提供します。これにより、ハイブリッドクラウドアーキテクチャ全体で一貫したセキュリティとコンプライアンスを確保できます。詳細については、AWS Control Tower のドキュメントを参照してください。
ガードレールなどの AWS Control Tower および 機能は、政府や金融サービス機関 (FSIs) などの規制対象業界のデータレジデンシー要件に準拠するように設定できます。エッジでデータレジデンシーのガードレールをデプロイする方法については、以下を参照してください。
-
ランディングゾーンコントロール AWS Local Zones を使用して のデータレジデンシーを管理するためのベストプラクティス
(AWS ブログ記事) -
AWS Outposts ラックとランディングゾーンのガードレールを使用したデータレジデンシーの設計
(AWS ブログ記事) -
Hybrid Cloud Services レンズによるデータレジデンシー (AWS Well-Architected Framework ドキュメント)
Outposts リソースの共有
Outpost はデータセンターまたはコロケーションスペースに存在する有限のインフラストラクチャであるため、 を一元管理するには AWS Outposts、どのアカウント AWS Outposts リソースを共有するかを一元的に制御する必要があります。
Outpost 共有を使用すると、Outpost 所有者は Outpost サイトやサブネットを含む Outpost と Outpost リソースを、同じ組織内の他の AWS アカウント と共有できます AWS Organizations。Outpost 所有者は、Outpost リソースを一元的に作成および管理し、 AWS 組織 AWS アカウント 内の複数の 間でリソースを共有できます。これにより、他のコンシューマーは Outpost サイトを使用したり、VPC を設定したり、共有 Outpost 上でインスタンスを起動して実行したりできるようになります。
の共有可能なリソース AWS Outposts は次のとおりです。
-
割り当てられた専用ホスト
-
キャパシティ予約
-
お客様所有の IP (CoIP) アドレスプール
-
ローカルゲートウェイルートテーブル
-
Outposts
-
Amazon S3 on Outposts
-
サイト
-
サブネット
マルチアカウント環境で Outposts リソースを共有するためのベストプラクティスに従うには、次の AWS ブログ記事を参照してください。