この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、佐伯です。
すでに日本に帰ってきていますが、去年もレポートした「Best Practices for Securing an Amazon VPC」の資料がSlideShareにアップロードされていましたので、読んでみました！なお、今年もワークショップ形式だったようですので、ハンズオン部分については省略しております。
スライド
[slideshare id=124110014&doc=best-practices-for-securing-an-45fdc54b-3531-41af-8086-4b4b19668203-980042629-181127005631]
概要
このインタラクティブなワークショップでは、安全なAmazon仮想プライベートクラウド（Amazon VPC）の設計と構築に関する実践的なアドバイスとガイダンスを提供します。 ハンズオンアプローチを使用して、サブネット、セキュリティグループ、AWS PrivateLink、ネットワークACL、ルーティング、フローログ、サービスエンドポイントなどのAmazon VPC機能を使用します。 また、大規模なインフラストラクチャを運用しているお客様をサポートしてきた経験に基づいて、VPCの設計と管理に関するベストプラクティスを共有しています。 あなた自身のラップトップを持参することをお勧めします。
スピーカー
Corina Motoi - Solution Architect
Matt Johnson - Manager, Solutions Architecture, WWPS, AWS
Amazon VPCコントロールプレーンのセキュリティ保護
目的
VPCを管理する権限を設定し設定の変更を追跡/監査する方法を学ぶ
- VPCの設定を保護するAWSサービス
- AWS Identity and Access Management(IAM)
- 変更を追跡/監査するAWSサービス
- AWS CloudTrail
- AWS Config
VPCを管理する権限の設定
AWS Identity and Access Management(IAM)
原則:
- VPCリソースにアクセスするときに、最低限のアクセス権を許可する
次の項目を評価:
- どのタイプのユーザーがVPCのリソースにアクセスするか?
- ユーザーはどのVPCリソースにアクセスできるか?
- ユーザーはどのようなタスクを実行する必要があるか?
最低特権アクセス:
- アイデンティティ: ユーザ、グループ、ロール
- アクセス管理: ポリシーとアクセス許可
IAMの仕組み
- プリンシパル
- ユーザー、アカウント、サービスなどを指定
- 承認
- アクションレベルの許可
- リソースレベルの許可
- リソースベースの許可
- タグベースの許可
- リービスリンクロール
- リソース
AWSドキュメント: IAM の詳細を理解します。 - AWS Identity and Access Management
IAMポリシーの構造
- JSONドキュメント
- ステートメント(パーミッション)の指定を含む
- プリンシパルが実行できるアクション
- どのリソースにアクセスできるか
- 複数のステートメントを記述でき、各ステートメントはPARC(Principal, Action, Resource, Condition)で構成される
AWSドキュメント: ポリシーとアクセス許可 - AWS Identity and Access Management
設定の変更を追跡/監査
AWS CloudTrail
- AWS APIの呼び出しに関するイベントをキャプチャしてログに記録する
- ユーザーとリソースのアクティビティの可視化に役立つ
- セキュリティ及び運用上の問題の発見とトラブルシューティングに役立つ
AWS Config & AWS Config rules
- AWS Config
- 継続的にAWSリソースの変更を記録
- AWSリソースの設定変更の時系列ビュー
- アーカイブと比較
- AWS Config rules
- ベストプラクティスを強制する
- 不要な変更を自動的にロールバック
- 追加のワークフローをトリガー
VPCトラフィックフローのコントロール
目的
VPCトラフィック制御メカニズム、AWSの外部との接続、AWSサービスへのプライベート接続、またはマルチVPCアーキテクチャのために使用する方法を理解する。
- VPCセキュリティの基本的なサービス
- Internet Gateway
- NAT Gateway
- VPC接続パターンのベストプラクティス
- VPC Peering
- VPC Gateway Endpoint
- VPCエンドポイントとAWS PrivateLinkを使った接続
- AWS PrivateLink
VPCトラフィックコントロールのメカニズムを理解する
- サブネット
- アベイラビリティゾーン固有のもので、パブリックまたはプライベートに設定できる
- セキュリティグループ
- インスタンスはまたENIに対して仮想ファイアウォールとして動作し、インバウンドおよびアウトバウンドトラフィックを制御する
- 相互参照することができる(同一リージョン内)
- ルートテーブル
- ルートと呼ばれる一連のルールが含まれており、ネットワークトラフィックがどこに向かうかを判断するために使用
- VPCの各サブネットはルートテーブルに関連付けられている必要がある
- ネットワークACL(NACL)
- VPCのセキュリティオプション
- ひとつまたは複数のサブネットに出入りするトラフィックを制御する
セキュリティグループとネットワークACLの比較
| セキュリティグループ | ネットワークACL |
|---|---|
| インスタンスレベルで動作する | サブネットレベルで動作する |
| 許可ルールのみ設定可能 | 許可および拒否ルールを設定可能 |
| ステートフル(戻り通信は自動で許可される) | ステートレス(戻り通信の許可ルールを設定する必要がある) |
| 全てのルールが評価される | ルール番号の低い順に評価され一致するルールがあれば以降の評価は行わない |
| インスタンスに明示的に関連付けた場合に適用される | 関連付けられたサブネット内の全てのインスタンスに自動的に適用される |
セキュリティグループとネットワークACLはリンクローカルアドレス (169.254.0.0/16) またはAWS予約済みIPアドレスとやり取りされるトラフィックをフィルタリングしません。AWS予約済みアドレスは、サブネットの最初の4個のIPアドレス (VPCのAmazon DNSサーバーアドレスを含む)
AWSドキュメント: セキュリティ - Amazon Virtual Private Cloud
ネットワークACLを使用する理由
- 役割の分離
- 異なるIAMアクションにより、セキュリティグループとネットワークACLの管理を分離できる
- 明示的な拒否ルールを指定できる
- 特定のIPアドレス/ポートをブラックリスト形式で登録できる
- 接続追跡されたトラフィックフローを切断する
- セキュリティグループを削除した際、そのトラフィックがすぐに中断されるようにする場合にネットワークACLを使用する(*)
*接続追跡
落とし穴
- セキュリティグループは同一サブネットであってもインスタンス間の通信を暗黙的に許可しない
- セキュリティグループのルールにプライベートアドレスを設定した場合は、プライベートアドレス宛の通信に対して機能する
- VPC内からパブリックIPへのアクセスは送信元がパブリックIPアドレスとなる
- ELBを使用する際のネットワークACLでの注意
- ELBからバックエンドへのヘルスチェック通信を許可する
- ELB通信は同一サブネットであってもVPCルーターを経由する
AWSの外部とのトラフィックコントロール
インバウンド通信
アウトバウンド通信
オンプレミスとの接続オプション
AWSの内部とのトラフィックコントロール
AWSサービスへのプライベート接続
- ユースケース
- VPCへのDX/VPN接続のみを使用するシナリオ
- VPCからインターネットへの出力がない(したがってAWS APIエンドポイントをコールできない)
- ベストプラクティス
- VPCからの発信トラフィックのみを許可することで攻撃対象を減らす
- これをサポートするサービス
- VPCエンドポイント
VPCエンドポイント
インターネットゲートウェイ、NATゲートウェイがない場合、パブリックIPアドレスが必要となる。
- VPCゲートウェイエンドポイント
- VPC内からプライベートネットワークでS3とDynamoDBへのアクセスが可能
- IAMベースアクセスコントロール
- VPCインターフェイスエンドポイント(AWS PrivateLink)
- VPC内からプライベートIPアドレスで指定したAWSサービス、またはユーザーのエンドポイントにアクセス可能
- セキュリティグループでのアクセスコントロール
VPCゲートウェイエンドポイントのアクセスコントロール
- 堅牢なアクセス制御
- ルートテーブルアソシエーション
- リソースポリシー(S3エンドポイント)
- VPCエンドポイントポリシー
- セキュリティグループ内でプレフィックスリスト指定
VPCエンドポイントポリシー
- VPCエンドポイントポリシーはエンドポイントを作成または変更するときにアタッチできるIAMリソースポリシーです
- エンドポイントポリシーはIAMユーザーポリシーやサービス固有のポリシー(S3バケットポリシーなど)に代わるものではない
- 複数のポリシーをエンドポイントに追加することはできない
プレフィックスリストとセキュリティグループ
- ターゲットへの論理的なルート
- S3プレフィックスリストは、S3で使用されるパブリックIP範囲を表す
- セキュリティグループのルールとして指定可能
AWSドキュメント: ゲートウェイエンドポイントのルーティング
VPCインターフェイスエンドポイント(AWS PrivateLink)のアクセスコントロール
- インターフェイスエンドポイントはVPC内に作成される
- アベイラビリティゾーンごとにENIが作成される
- VPCサブネット内のIPアドレスがアサインされる
- DX, VPN, インターリージョンVPCピアリングからもアクセス可能
- プライベートDNS名のサポート
- ENIにセキュリティグループを関連付け可能
-
現在サポートしているサービス
- インターフェイス VPC エンドポイント (AWS PrivateLink) - Amazon Virtual Private Cloud
- 他のAWSアカウントが提供しているサービス
- AWS Marketplaceパートナーサービス
マルチVPCアーキテクチャでのトラフィックコントロール
- ユースケース
- ２つ以上のVPCをピアリングしてリソースへのアクセスを提供する
- ひとつのVPCをピアリングして集中型のリソースにアクセスする
- ベストプラクティス
- "Minimize blast radius for users and networks"
- ユーザーとネットワークへの影響範囲を最小限に留める?
- これをサポートするサービス
- VPCピアリング
- AWS PrivateLink
VPCピアリング
- ふたつのVPC間のネットワーク接続
- 以下のピアリング接続を行うことが可能
- 同じAWSアカウント内のVPCと
- 他のAWSアカウントのVPCと
- 別のリージョンのVPCと
- Amazon VPCのインフラストラクチャを使用している
- ボトルネックはない
- 単一障害点はない
AWS PrivateLink
- SaaSサービスを安全に提供するのに最適
- テナント:
- シングルテナントモード:すべてのクライアント/顧客用にPrivateLink用のNLBを作成
- マルチテナントモード:すべてのクライアント/顧客が同じPrivateLinkのNLBを使用
- エンドポイントにリージョンDNSホスト名とゾーンDNSホスト名がある
AWS PrivateLinkの役立つ情報
- どうやってエンドポイントへのトラフィックを区別するのか?
- アカウント/パスワード/セキュリティトークンをアプリケーションレベルで使う
- NLBを分割、ターゲットで違うリスナーポートを使用する
- ProxyProtocalV2プリアンブルを有効にする
- 一方向のみのトラフィックをサポート
- TCPのみサポート、UDPはサポートしていない。
VPCピアリングとAWS PrivateLinkの比較
VPCモニタリングと自動修復
目的
VPC関連の監視ツールと、それらを使用してセキュリティ違反を検出および修復する方法について説明します。
VPCモニタリングの役割はなにか?
- IPトラフィックフローの監視
- 悪意のある行為や許可されていない行為の検出
- 自動修復のトリガー
VPCモニタリングのツールとサービス
VPCフローログ
VPC内のネットワークインターフェイスで送受信されるIPトラフィックをキャプチャする。
- ユースケース
- 過度に制限的なセキュリティ制御の診断
- インスタンスに到達するトラフィックの監視
- 特定種類のトラフィックに応じてトレンドを特定しアラームを作成
VPCフローログのフォーマット
AWSドキュメント: フローログレコード
VPCフローログの役立つ情報
- トラフィックがセカンダリIPアドレスを持つENI宛に送信されても、フローログの送信先IPアドレスはプライマリIPアドレスが表示される
- フローログの API アクション (ec2:*FlowLogs) は、いずれもリソースレベルのアクセス権限をサポートしていない
- 以下のトラフィックはキャプチャされない
- Amazon DNSサーバー宛のトラフィック
- Windowsライセンスアクティベーションサーバー宛のトラフィック
- インスタンスメタデータ用の169.254.169.254宛のトラフィック
- DHCPリクエストとDHCPレスポンスのトラフィック
- デフォルトVPCルーターの予約済みIPアドレスへのトラフィック
Amazon GuardDuty
インテリジェントな継続的なセキュリティ監視と脅威検出、完全に管理された統合脅威インテリジェンス、異常検出、および機械学習サービスです。
Amazon GuardDutyの脅威検出タイプの詳細
AWSドキュメント: GuardDuty のアクティブな結果タイプ - Amazon GuardDuty
Amazon GuardDutyの役立つ情報
- GuardDutyがログタイプのいずれかを処理するためにロギングをオンにする必要はありません。
- 現在のところ、ユーザーはDNSログに直接アクセスすることはできず、実際にはGuardDutyはこれらのログを監視する唯一の手段です。
- GuardDutyは関連するサービスから直接取得するため、すべてのログはバックエンドですべて実行されます。 したがって、アーキテクチャーの変更、エージェントの不要、アカウントのパフォーマンスへの影響は不要です。
Amazon CloudWatchの役立つ情報
- CloudWatchはさまざまな機能を提供します
- メトリクス
- ダッシュボード
- ログ
- イベント
- アラーム
- CloudWatch Logsはさまざまなメリットを提供します
- ログデータの有用な集約ポイント
- データを他のサービスにプッシュする機能
- サードパーティのサービスとの統合
VPCモニタリングツールを使ってセキュリティ侵害を検出および修復する方法
CloudWatch Events概念の役立つ情報
- APIアクティビティによって駆動
- 概念
- イベント: AWS環境における変化を示す
- 他のAWSサービスによって生成される
- スケジュールによって生成される
- カスタムアプリケーションレベルのイベントによって生成される
- ターゲット: イベントを処理する対象
- ターゲットには例えばAWS Lambda、Kinesis Streams、Step Functionsなどを設定することができる
- ルール: 一致した受信イベントを検出し、イベント処理のためにターゲットに振り分 ける
- ひとつのルールで複数のターゲットを指定できる
- 並列に処理される
- Amazon CloudWatch Events busにより、組織内または組織間でCloudWatch Eventsを管理可能
自動修復のフロー例
最後に
自動修復に関してはデモだけだったのか特にスライドに資料はなかったです。サービス発表のタイミング的な問題なのか、マルチVPCアーキテクチャの部分でTransit Gatewayがでてこなかったので、以下のレポートも参考になるかと思います。
[レポート] NET402 – AWS Transit Gateway と Transit VPCs で複数 VPC のリファレンスアーキテクチャ #reinvent
7
