AWS Organizations 環境で SCP を使ってインターネットアクセス可能な VPC の作成を許可しない OU を作成してみた
いわさです。
AWS Organizations や Control Tower を使って組織の複数の AWS アカウントを管理したり統制したいことがよくあります。
その時、払い出した AWS アカウントを使ってワークロードから無許可でインターネットアクセスへ直接アクセスを許可したくないケースがあります。
AWS Organizaitons 公式ドキュメントの SCP (Service Control Policy) 例としてインターネットアクセスを出来ないようにする SCP の実装例が紹介されています。
マルチアカウント管理のガイダンスとして OU (Organization Unit) に役割を持たせる方法が紹介されています。
今回はセキュリティ制御としてインターネットアクセスを許可しない AWS アカウントを OU と SCP を使って制御してみたいと思います。
OU と SCP作成
まずはポリシーを適用するために適当な OU を作成しましょう。
検証用なのでなんでも良いのですが、7月からチバユキチームの一員となったのでchibayuki
という OU を作成しました。
次に SCP を用意します。
ポリシー内容は次のようなもので、冒頭の公式ドキュメントのポリシー内容のままです。
内容としては、インターネットゲートウェイの作成とアタッチを禁止していますね。
また、VPC ピアリングの作成・承認とグローバルアクセラレータの作成・更新も拒否しています。なるほど、そのあ通信経路もあったか。
そして作成した SCP を OU にアタッチします。
最後に、適当な検証アカウントを作成した OU に移動させましょう。
これでこのアカウントは、要はインターネットアクセスのために必要なコンポーネントを作成できなくなったので、このアカウントからインターネットアクセスされることはないだろう。ということですね。
インターネットゲートウェイを作成してみる
さて、該当アカウント上で早速インターネットアクセス可能な VPC を作成してみます。
まずは VPC 作成時に関連コンポーネントも自動作成してくれる便利機能を使って VPC などを作成してみましょう。
この機能では構成時にパブリックサブネットが 1 件以上ある場合はインターネットゲートウェイも作成される仕様のようです。
おお、作成に失敗しました。
インターネットゲートウェイの作成にだけ失敗していますね。よって、パブリックサブネットのない VPC であれば新規作成は可能です。
また、インターネットゲートウェイ単独での作成も失敗しました。良さそう。
グローバルアクセラレータと VPC ピアリングも作成出来ない
同様にポリシーに記載のあった他のコンポーネントも確認してみましょう。
次はグローバルアクセラレータの作成失敗の様子です。
こちらは VPC ピアリング作成失敗の様子です。
なお、今回のポリシーはインターネットアクセスするためのコンポーネントの作成などを制限するものになっているので既にインターネットゲートウェイなどがアタッチされた VPC が存在する場合は影響を受けずに引き続きインターネットアクセスが可能です。
そういえばデフォルト VPC あったな
今回気がついたのですが、そういえばデフォルト VPC というものがありましたね。
そして、このデフォルト VPC はインターネットゲートウェイがアタッチされています。
セキュリティ向上のためのデフォルト VPC は削除しましょうという運用もよくあります。
既に存在する環境であればスクリプトで全リージョン削除するとか、あるいは新規アカウントに関しては Account Factory を使ってデフォルト VPC を削除する方法も考えられます。
デフォルト VPC 作成出来るのか?
デフォルト VPC は不要であれば削除し、必要になったタイミングで再作成が可能です。
作成するには通常の VPC を作成してデフォルト VPC として選択するのではなく、「デフォルト VPC 作成」という機能を使う必要があります。
先ほどの制限されたアカウントで削除と再作成を試してみましょうか。
まずデフォルト VPC を削除します。削除確認キーワードを入力したのですが削除ボタンが押せません。よく見ると VPC の前後に半角スペースが必要なようです。なんてこったい。
デフォルト VPC が削除されている場合、VPC コンソールのアクションメニューから「デフォルト VPC を作成」のボタンが押せるようになりますのでこちらを押しましょう。
なんと、デフォルト VPC が作成出来てしまいました。
そしてインターネットゲートウェイも一緒に作成されアタッチされています。
インターネットアクセス可能な VPC を作成させないためのポリシーなのですがデフォルト VPC で作成出来てしまう状態となっていました。
この挙動について次の公式ドキュメントに記述があります。
Amazonは、ユーザーに代わって上記のリソースを作成します。ユーザーがこれらのアクションを実行するわけではないため、IAM ポリシーはこれらのアクションに適用されません。たとえば、CreateInternetGateway を呼び出す機能を拒否する IAM ポリシーがあり、CreateDefaultVpc を呼び出した場合でも、デフォルト VPC 内のインターネットゲートウェイが作成されます。
SPC でデフォルト VPC 作成も拒否するように修正
というわけで、より厳格にやるのであればデフォルト VPC の作成も拒否するのが良さそうです。
IAM コンソールを確認してみるとデフォルト VPC 作成には次のアクションが必要なようです。
こちらを SCP に追記します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:AttachInternetGateway",
"ec2:CreateInternetGateway",
"ec2:CreateEgressOnlyInternetGateway",
"ec2:CreateVpcPeeringConnection",
"ec2:AcceptVpcPeeringConnection",
"globalaccelerator:Create*",
"globalaccelerator:Update*",
"ec2:CreateDefaultVpc"
],
"Resource": "*"
}
]
}
ポリシーの更新後に再度デフォルト VPC 作成を試してみましょう。
今度はこちらも拒否されましたね。良さそうです。
さいごに
本日は AWS Organizations 環境で SCP を使ってインターネットアクセスを許可しない OU を作成してみました。
インターネットゲートウェイを制限しインバウンドだけなくアウトバウンドも拒否するので、完全に閉域にするのではなくインバウンドだけ拒否したいみたいな時はこの方法は取れなさそうですが。
インターネットゲートウェイ以外にもインターネットアクセスするための経路があったりとか、あるいはデフォルト VPC の特殊な仕様があったりといくつか気づく点もありました。
ただ、まだいくつか抜け道がありそうな気もしますね。
VPC ピアリング以外にも VGW を経由するような別のネットワーク経路でインターネットアクセスするなども出来そうなのでそのあたりも追加で考慮しても良さそうです。