Private Service Integration

1. プライベートサブネットとプライベートサービス統合を分ける

ワークロードがプライベートサブネットに存在していても、NAT ゲートウェイを経由してAWSサービスのパブリックエンドポイントへ到達する構成は成立します。

プライベートサブネット
     ↓
NATゲートウェイ
     ↓
AWSサービスパブリックエンドポイント

したがって「パブリックIPがない」だけではパブリックインターネット回避の要件を満たしたとは判断しません。対象宛先までの実際のネットワーク経路を確認します。

2. エンドポイント候補より先にセキュリティ要件を分解する

エンドポイント方式そのものではなく、これらの要件を満たす制御組み合わせを選びます。

3. 既習の接続方式をセキュリティ制御へ配置する

ゲートウェイエンドポイント、インターフェイスエンドポイント、AWS PrivateLinkの基本的な選択条件は既習です。ここでは接続方式そのものを再説明せず、選んだプライベート経路へ必要な制御を配置します。

既習の接続候補
        ↓
ネットワーク到達性
        ↓
エンドポイント経由の認可
        ↓
プリンシパル権限
        ↓
リソース側の経路制限

試験では「エンドポイントがあるか」だけでなく、承認した経路以外を迂回できないかまで確認します。

4. プライベート経路が存在してもネットワーク到達性は別に絞る

インターフェイスエンドポイントでは、利用側からエンドポイントENIへ到達できるネットワーク送信元をセキュリティグループで制限できます。

アプリケーションSG
     │ HTTPS 443
     ▼
インターフェイスエンドポイント SG
     │
     ▼
AWS PrivateLink
     │
     ▼
AWSサービス

「プライベートエンドポイントだから安全」とまとめず、必要なアプリケーション層だけがエンドポイントへ到達できるかを確認します。

5. DNS名ではなく名前解決結果と実際の経路を見る

通常のAWSサービスDNS名を使用していても、サービスが対応しプライベートDNSを有効にしたインターフェイスエンドポイントではプライベートIPへ名前解決される場合があります。またゲートウェイエンドポイントではサービスプレフィックスリスト宛ルートによってプライベート経路が選択されます。

サービスDNS名
        ↓
DNS名前解決
        ↓
名前解決後の宛先
        ↓
ルート/ エンドポイント
        ↓
実際のネットワーク経路

プライベートDNSの対応や挙動はサービスごとに確認します。DNS名の文字列だけでパブリック/ プライベートを決めません。

6. エンドポイントポリシーはエンドポイントを通るアクセス範囲を制御する

エンドポイントポリシーをサポートするサービスでは、エンドポイントを経由して許容するプリンシパル / アクション / リソースを絞れます。

エンドポイントを通れる？
        ↓
エンドポイントポリシー
        ↓
プリンシパル自身に権限がある？
        ↓
IAM / リソースポリシー等
        ↓
アクセス成立

エンドポイントポリシーはIAM アイデンティティポリシーやサービスリソースポリシーを置き換えません。プライベート接続と認可を別条件として評価します。

7. エンドポイントを作ることとリソースをそのエンドポイントに限定することは別

エンドポイントポリシーは、そのエンドポイントを通過するリクエストを制御します。要件が「特定リソースは承認VPCエンドポイント経由でしか利用させない」である場合、リソース側でもネットワークコンテキストを使った制限が必要になることがあります。

アプリケーション
    │
    ▼
承認済み VPCエンドポイント
    │ エンドポイントポリシー
    ▼
Amazon S3バケット
    │
    └─ バケットポリシー
       aws:SourceVpce 等を評価

Amazon S3ではバケットポリシーでaws:SourceVpceを利用し、指定エンドポイント以外からのリクエストを拒否できます。

8. リソース側で経路を強制する前に正当なアクセス経路を列挙する

ネットワークコンテキストによる拒否を強くすると、アプリケーション以外の正当なアクセスまで遮断することがあります。

リソースへ必要なアクセス経路
├─ アプリケーション承認済みエンドポイント経由
├─ 運用 / 管理経路
├─ AWSサービスからの連携
└─ その他必要な連携
        ↓
不要経路だけを拒否できる？
        ↓
リソースポリシーを設計

例えばS3で指定エンドポイント以外を一律拒否すると、AWS Management Consoleからのアクセスも拒否される場合があります。またAWSサービスが別サービスを呼ぶフローではネットワークコンテキストの扱いが異なる場合があります。最も厳しいポリシーではなく、必要アクセスを維持しながら不要経路を閉じます。

9. PrivateLinkでは提供側でも利用側を制御する

プライベートサービスをAWS PrivateLinkで公開する場合、利用側ネットワーク制御だけでなく提供側でも接続可能なプリンシパルと接続承認を確認します。

利用側アカウント
      │
      │ 許可済みプリンシパル ?
      ▼
エンドポイント接続リクエスト
      │
      │ 承認が必要？
      ▼
提供側エンドポイントサービス

「アカウント Bだけエンドポイントを作成できる」と「アカウント Bの接続リクエストを個別承認する」は別制御です。

10. PrivateLinkをサービス境界の制御へ接続する

AWS PrivateLinkでサービス単位に公開する考え方は既習です。ここでは、その接続を承認した利用者だけが使える状態へ完成させます。

提供対象サービス
        ↓
許可するプリンシパル
        ↓
必要なら接続承認
        ↓
利用側エンドポイントの到達性 / ポリシー
        ↓
承認済み利用経路

サービス単位で接続できても、提供側・利用側の許可範囲が広すぎればセキュリティ要件を満たしません。

11. 依存関係ごとに承認経路を監査する

プライベートエンドポイントを作成した事実だけでは、「必要通信がすべて承認経路を通る」ことの証明にはなりません。アプリケーションの依存先ごとに実際の経路と残存する別経路を確認します。

経路変更は依存関係の一覧とセットで評価し、1つのエンドポイント追加をVPC全体の送信経路変更と同一視しません。

12. 制御組み合わせで要件を完成させる

機密S3バケットへのアクセスを例にすると、1つの制御へすべての責任を持たせません。

プライベート接続
        +
最小権限プリンシパル
        +
エンドポイントの認可
        +
リソース側の制限
        ↓
セキュリティ要件成立

13. 候補比較

14. 判断フロー

プライベート接続要件
        ↓
必要な宛先を列挙
        ↓
パブリック送信を許容？
        ↓ いいえ既知のプライベートエンドポイント候補を適用
        ↓
実際のプライベート経路が成立？
        ↓
エンドポイントへのネットワーク到達性は適切？
        ↓
エンドポイント経由のアクセス範囲を制限する？
        ↓
プリンシパル自身の権限は適切？
        ↓
リソース側でも承認済み経路を強制する？
        ↓ はい正当なアクセス経路をすべて列挙
        ↓
不要経路だけを拒否
        ↓
プライベートサービス提供側なら許可済みプリンシパル / 承認を確認
        ↓
他依存関係にパブリック送信が残る？
        ↓
要件成立

15. 混同ポイント

16. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
• ゲートウェイエンドポイント
• インターフェイスVPCエンドポイントを使用したAWSサービスへのアクセス
• エンドポイントポリシーを使用したVPCエンドポイントへのアクセス制御
• エンドポイントサービスの設定
• Amazon S3バケットポリシーによるVPCエンドポイントからのアクセス制御
• AWSグローバル条件コンテキストキー