SEC09-BP03 ネットワーク通信を認証する - セキュリティの柱
実装のガイダンスリソース

SEC09-BP03 ネットワーク通信を認証する

Transport Layer Security (TLS) や IPsec など、認証をサポートするプロトコルを使用して、通信の ID を検証します。

サービス間、アプリケーション間、またはユーザーへの通信には常に、安全で認証済みのネットワークプロトコルを使用するようにワークロードを設計してください。認証と認可をサポートするネットワークプロトコルを使用すると、ネットワークフローをより強力に制御し、不正アクセスの影響を軽減できます。

期待される成果: ワークロードで、サービス間のデータプレーンとコントロールプレーンのトラフィックフローが明確に定義されます。技術上可能な場合は必ず、認証および暗号化されたネットワークプロトコルをトラフィックフローが使用する。

一般的なアンチパターン:

  • ワークロード内のトラフィックフローが暗号化されていない、または認証されていない。

  • 複数のユーザーやエンティティで認証情報を再利用している。

  • アクセス制御のメカニズムとしてネットワーク統制にばかり依存している。

  • 業界標準の認証メカニズムに頼る代わりに、カスタムの認証メカニズムを作成する。

  • VPC 内のサービスコンポーネントや他のリソース間のトラフィックフローが必要以上に許可されている。

このベストプラクティスを活用するメリット:

  • 不正アクセスによる影響が及ぶ範囲をワークロードの一部に制限します。

  • アシュアランスのレベルを上げ、認証済みのエンティティだけがアクションを実行するように徹底します。

  • 導入予定のデータ転送インターフェイスを明確に定義し、実際に導入して、サービスの分離を強化します。

  • リクエストのアトリビューションと、明確に定義された通信インターフェイスにより、モニタリング、ログ記録、インシデント対応を強化します。

  • ネットワーク統制に認証と認可の制御を組み合わせることで、ワークロードに多層防御を提供します。

このベストプラクティスを活用しない場合のリスクレベル: 低

実装のガイダンス

ワークロードのネットワークトラフィックのパターンは、次の 2 つのカテゴリに分類できます。

  • East-West トラフィックは、特定のワークロードを構成しているサービス間のトラフィックフローを表します。

  • North-South トラフィックはワークロードとコンシューマー間のトラフィックフローを表します。

一般的には North-South トラフィックを暗号化し、認証済みプロトコルを用いて East-West トラフィックを保護する例はあまり見られません。最近のセキュリティ対策では、ネットワークの設計だけで、2 つのエンティティ間に信頼関係があるとは想定しないというのが通例となっています。2 つのサービスが共通のネットワーク境界内に存在する場合でも、それらのサービス間の通信を暗号化し、認証と認可を行うことがベストプラクティスです。

例えば、AWS サービス API は、リクエストの発信側のネットワークに関係なく、AWS Signature Version 4 (SigV4) 署名プロトコルを使用して発信者を認証します。この認証により、AWS API はアクションをリクエストした ID を検証し、その ID をポリシーと組み合わせて、アクションを許可するかどうかを判断する認可決定を行うことができます。

Amazon VPC Lattice や Amazon API Gateway などのサービスでは、同じ SigV4 署名プロトコルを使用して、独自のワークロードの East-West トラフィックに認証と認可を追加できます。SigV4 ベースの認証と認可が要求されるサービスに AWS 環境外のリソースから通信する必要がある場合は、非 AWS リソースに AWS Identity and Access Management (IAM) Roles Anywhere を使用することで、一時的な AWS 認証情報を取得できます。これらの認証情報は、SigV4 を使用してサービスへのリクエストに署名して、アクセスの認可を受けるために使用できます。

East-West トラフィックを認証するメカニズムとしては、TLS 相互認証 (mTLS) も一般的です。モノのインターネット (IoT)、ビジネス間アプリケーション、マイクロサービスの多くは、mTLS を採用しています。TLS 通信のクライアント側とサーバー側の両方が X.509 証明書を使用して、双方のアイデンティティを認証し合います。これらの証明書は AWS Private Certificate Authority (AWS Private CA) で発行できます。Amazon API Gateway などのサービスを使用して、ワークロード間またはワークロード内の通信で mTLS 認証を行うことができます。Application Load Balancer は、内部または外部向けワークロードの mTLS もサポートしています。mTLS は TLS 通信の両側に認証情報を提供しますが、認証のメカニズムは提供しません。

最後に、OAuth 2.0 と OpenID Connect (OIDC) の 2 つのプロトコルは、ユーザーがサービスへのアクセスを制御する際によく利用されていますが、最近はサービス間のトラフィックにもよく利用されています。API Gateway の JSON ウェブトークン (JWT) オーソライザーを使用すると、OIDC または OAuth 2.0 の ID プロバイダーが発行した JWT を使用して、API ルートへのアクセスをワークロードで制限することができます。OAuth2 のスコープを基本的な承認決定のソースとして使用できますが、依然として承認チェックをアプリケーション層に実装する必要があります。OAuth2 スコープ単体で複雑な承認ニーズに対応することはできません。

実装手順

  • ワークロードのネットワークフローを定義し文書化する: 多層防御戦略を実装するには、まずワークロードのトラフィックフローを定義します。

    • ワークロードを構成するさまざまなサービス間でデータがどのように転送されるかを明確に定義したデータフロー図を作成します。これらのフローを認証済みのネットワークチャネルに実際に流していく前に、まずこの図を用意します。

    • 開発段階とテスト段階でワークロードを計測して、ランタイム時のワークロードの動作がデータフロー図に正確に反映されていることを確認してください。

    • データフロー図は、脅威モデリングを行う (「SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける」を参照) ときにも役立ちます。

  • ネットワーク統制を確立する: データフローに応じたネットワーク統制を確立するときは AWS の機能を使用することを検討します。ネットワーク境界は、それだけでは十分なセキュリティ統制にはなりませんが、ワークロードを保護する多層防御戦略の 1 層にはなります。

    • リソース間のデータフローの確立、定義、制限には、セキュリティグループを使用します。

    • AWS サービスと、AWS PrivateLink をサポートしているサードパーティーのサービスの両方と通信するときは、AWS PrivateLink の使用を検討します。AWS PrivateLink インターフェイスエンドポイントを介して送信されるデータは、AWS ネットワークバックボーン内にとどまり、公開インターネットを経由しません。

  • ワークロード内のサービス間に認証と認可を実装する: ワークロード内のトラフィックフローの認証と暗号化を実現するために最も適した AWS サービスのセットを選択します。

  • 不正アクセスを監視する: 意図しない通信チャネル、不正なプリンシパルによる保護済みリソースへのアクセス、その他不適切なアクセスパターンを継続的にモニタリングします。

    • VPC Lattice を使用してサービスへのアクセスの管理するときは、VPC Lattice アクセスログを有効にしてモニタリングすることを検討します。これらのアクセスログには、リクエスト元のエンティティに関する情報、ソースとターゲットの VPC などのネットワーク情報、リクエストのメタデータが記録されています。

    • ネットワークフローのメタデータをキャプチャし、異常がないか定期的に点検するときは、VPC フローログを有効にすることを検討します。

    • セキュリティインシデントのプランニング、シミュレーション、対応に関する解説は、「AWS セキュリティインシデント対応ガイド」および「セキュリティの柱 - AWS Well-Architected Framework」内の「インシデント対応」のセクションを参照してください。

リソース

関連するベストプラクティス:

関連ドキュメント:

関連動画:

関連する例: