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 トラフィックに認証と承認を追加できます。AWS 環境の外のリソースが、SigV4 ベースの認証と承認を必要とするサービスと通信する必要がある場合は、その非 AWS リソースで AWS Identity and Access Management (IAM) Roles Anywhere を使用して、一時的な AWS 認証情報を取得できます。この認証情報を使用して、アクセス権の承認に SigV4 を使用するサービスへのリクエストに署名できます。

East-West トラフィックを認証するメカニズムとしては、TLS 相互認証 (mTLS) も一般的です。モノのインターネット (IoT)、ビジネス間 (B2B) アプリケーション、マイクロサービスの多くは、mTLS を採用しています。TLS 通信のクライアント側とサーバー側の両方が X.509 証明書を使用して、双方のアイデンティティを認証し合います。これらの証明書は AWS Private Certificate Authority (AWS Private CA) で発行できます。Amazon API Gateway や AWS App Mesh などのサービスを使用して、ワークロード間またはワークロード内の通信で 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 サービスを選択してください。

    • Amazon VPC Lattice でサービス間通信のセキュリティを確保することを検討してください。VPC Lattice では、SigV4 認証を認証ポリシーと組み合わせて使用して、サービス間のアクセスを制御できます。

    • mTLS を使用するサービス間通信では、API Gateway または App Mesh を検討してください。AWS Private CA を使用して、mTLS で使用する証明書を発行可能なプライベート CA 階層を確立できます。

    • OAuth 2.0 または OIDC を使用するサービスと統合する場合は、API Gateway で JWT オーソライザーを使用することを検討してください。

    • ワークロードと IoT デバイス間の通信については、AWS IoT Core を検討してください。IoT Core は、ネットワークトラフィックの暗号化と認証のオプションをいくつか提供します。

  • 不正アクセスを監視する: 意図しない通信チャネル、保護されたリソースにアクセスしようとする非承認のプリンシパル、その他の不適切なアクセスパターンを継続的に監視します。

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

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

    • セキュリティインシデントの計画、シミュレーション、対応に関する詳細なガイダンスについては、「AWS セキュリティインシデント対応ガイド」および「AWS Well-Architected フレームワーク」の「セキュリティの柱」の「インシデント対応」セクションを参照してください。

リソース

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

関連するドキュメント:

関連動画:

関連する例: