この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、岩城です。
セッション概要
SPEAKERS
- Becky Weiss
DESCRIPTION
このセッションでは、ネットワーク境界を、クラウド上のデータを取り巻くわかりやすい防御境界として利用する方法を学びます。VPCエンドポイントは、2015年にAmazon S3向けに初めて導入されて以来、多くの改善、強化、拡張が盛り込まれています。これらは、ネットワーク全体のセキュリティインバリアントを主張するだけでなく、データをネットワークにロックすることを可能にします。このセッションでは、VPCエンドポイントで何ができるかについての実践的なガイダンスを提供し、データ境界戦略の一環としてどのように構成するかを詳しく説明します。
SESSION LEVEL
300 - Advanced
レポート
- 発表者の方は、２０１５年当時VPCチームに所属しており、VPCエンドポイントに深く関わっていた
- AWSギークのために、どのように誕生したのか、その歴史を少しだけ紹介する
アジェンダ
- VPCからAWSサービスへの接続方法の歴史
- VPCエンドポイントがどのように機能するか第一原理からdeep dive
- 現代のクラウド環境にとっての意味(Builders向け)
Amazon EC2ネットワークの歴史
- EC2は今日のVPCよりも前に存在するサービスであり、EC2クラシックと呼ばれていた
- 今とは違いインターネットからの接続要件がなくとも、接続ルートは必ず存在していた
- 10.から始まるプライベートIPとパブリックIPが割り当てられていた
- 当時EC2以外にもいくつかサービスがあり、S3も含まれていた
- S3はインターネットに公開されたエンドポイントに存在しており、インターネットへの経路を持っているEC2もアクセスできた
- 多くの顧客企業から「クラウド上のインフラとオンプレのインフラを併用してネットワーク接続したい」という声があがってきた
- 10.から始まるIPアドレス範囲だとオンプレと競合してしまう。。そこで登場したのか今日のVPC
- 2008~2009年にかけてVPCが登場、初期はVPCとオンプレをVPNで接続（DXはなかった）
- S3はVPCの外にあるサービスのため、プライベートサブネットにあるEC2からアクセスできない
- アクセスさせるにはNATGW-IGWを経由する必要があった
- お客様は「S3にアクセスするためにIGWを経由する必要がなく、VPCから直接アクセスできること」を望んでいた
- 理由1:当時も今もネットワークをセキュリティの境界線の一部と考えているから
- ネットワークは決してセキュリティ境界の一部ではないし、ネットワークだけがセキュリティ境界の一部でもない
- 適切なネットワークからのアクセスだからといって、なんでもアクセスを許可することはセキュリティのベストプラクティスではない
- 理由2:VPC内にデータを配置できれば、そのデータにアクセスできるネットワークについてルールを作成できるから
- 自分のVPC外からのアクセスを防げる
- そこで登場したのがゲートウェイ型のVPCエンドポイント
ゲートウェイ型VPCエンドポイント
- 接続性
- インターネットへのアウトバウンドルートを必要としないサービスへのアクセス
- 認証
- VPCから発信されたトラフィックであることを識別する
- 境界ポリシー
- VPCから発信されるすべてのサービストラフィックを対象とする
- VPCエンドポイントから発信されたリクエストは
aws:SourceVpcとaws:SourceVpceが設定される aws:SourceVpcを利用して、特定のVPC以外からのアクセスを拒否させるバケットポリシーの例
- IAMロールにて、特定のVPC以外からのいかなるサービスへのアクセスを拒否させる
- VPCエンドポイントポリシーにて、あるAWS Organizationsの組織からのみアクセスを許可する
インターフェース型VPCエンドポイント(Private Link)
- Hyperplane技術を使ってVPCエンドポイントのコンセプトを拡張した
- Private Linkを利用すれば、インターネットへのルートが無くとも、VPC間やアカウント間の接続を可能にする
- ゲートウェイ型VPCエンドポイントとPrivate Linkの仕組みは全く違う
- Private Linkを作成すると、サブネット内にENIも作成され、サブネットCIDRの範囲でプライベートIPが設定される
- プライベートIPを持つので、オンプレからVPCを経由してKinesisにアクセスできる
- ゲートウェイ型の場合、VPCのプライベートIPを持たないのでオンプレからVPCを経由してS3にアクセスすることができない
- EC2からkinesisでDNS名を解決したいとする
- デフォルトではVPCのプライベートIPではなく、パブリックIPが返ってくる
- プライベートIPを返して欲しいので、VPCの設定でDNS名を有効化する
- VPCエンドポイントのDNS名でTLS証明書を確認するとワイルドカード名を持っていることがわかる
- VPCエンドポイントを使用するためには不必要な知識
インターフェース型VPCエンドポイントがS3に対応
- ゲートウェイ型ではオンプレからVPCを経由してS3にアクセスすることができない
- EC2でプロキシを構成したり頑張ればアクセスできる
- オンプレからS3にアクセスするために登場した
ゲートウェイ型がインターフェース型どちらを使ってS3にアクセスするか
- ゲートウェイ型
- 時間単位、GB単位の課金がない
- VPC内からの接続のみをサポート
- クライアントはS3のパブリックエンドポイントに到達
- インターフェース型
- インターフェース型VPCのエンドポイントとしての価格設（時間単位、GB単位、AZ単位）
- DX/VPN/TransitGWからの接続に対応
- クライアントはVPC内のプライベートIPでS3に到達
- VPCエンドポイント専用エンドポイントではクライアントの変更が必要
- オンプレからのS3アクセス要件がない限り、基本的にはゲートウェイ型のVPCエンドポイントを利用すること
ビルダーが知っておくべきこと
- この構成でAthenaを使ってS3バケットにあるデータにクエリする際、IAMロールに
"aws:ViaAwsService": "true"がないと失敗する
aws:ViaAwsService- AWSサービスがユーザーに代わって別のAWSサービスにリクエストを許可するかどうか
aws:PrincipalIsAwsService- AWSサービスからリソース対する直接リクエストを許可するかどうか
- 昨年のアップデートで
s3:ResourceAccount条件キーが追加された - AWSアカウントレベルでS3バケットのアクセス権限を定義可能になった
さらに:アウトバウンドトラフィックの管理について
- VPCからのDNSクエリを制御する（許可、拒否、アラート）
- Network Firewall用サブネットを作成する
- ステートレス、ステートフルパケットををフィルタリングする
感想
S3バケットへのアクセスを題材に、IAMロール、VPCエンドポイントポリシー、バケットポリシーの具体例を用いながら、データ境界の確保についてとても勉強になりました。
それだけじゃなく、AWS最初期のVPCから始まり、どうやってVPCエンドポイント（ゲートウェイ型、インターフェース型）できたのか歴史を知ることができましたし、顧客の声に耳を傾けるAWSの文化が根付いていることも再確認できました。
本エントリがどなたかのお役に立てれば幸いです。
61
