背景
AWS Transit Gatewayのピアリングアタッチメントを作成する際、任意のソースTransit Gatewayから宛先のTransit Gatewayへ接続をリクエストできます。この接続を確立するには、次の3つの情報が必要です。
- 宛先アカウントのAWSアカウントID
- 宛先Transit GatewayネットワークのTransit Gateway ID
- 宛先Transit Gatewayのリージョン
プロビジョニング後、アタッチメントはpending-acceptance(承認待ち)状態となり、宛先アカウントの承認を待ちます。しかし、特定の条件下ではソースアカウントがこの承認ステップを回避できてしまうセキュリティ上の不備が存在しました。
Pending Acceptance状態のTransit Gatewayアタッチメント
AWSコンソールでは、ソースアカウント(リクエスト元)側にも承認ボタンが表示されますが、押下すると以下のエラーになります。
ソースアカウントからの承認を拒否するAWSコンソール
承認できるのは宛先アカウントのみであるべきなので、これは想定どおりの挙動です。
ところが、AWS CLIからAWS APIを直接呼び出した場合、Transit Gatewayが別々のリージョン(例:アイルランドとロンドン)にあれば、ソースアカウント(リクエスト元)が適切な認可を経ずにピアリングリクエストを承認できてしまいました。
ソースアカウントでアタッチメントを承認した際のAWS CLIレスポンス
その結果、アタッチメントの状態は「Available」となり、ソースアカウント(不正な第三者である可能性もあります)に自社ネットワークへのアクセスを許してしまいます。つまり、ソースアカウント(=任意の第三者)が自社ネットワークにアクセスできる状態になるのです。
Available状態のTransit Gatewayアタッチメント
脆弱性の検知
本脆弱性はCloudTrailで追跡・確認できます。外部アカウントがアタッチメントリクエストを承認した際の操作ログが残ります。
宛先アカウント側のCloudTrailログ
脆弱性への対策
幸い、SCP(サービスコントロールポリシー)を使えばAcceptTransitGatewayPeeringAttachment APIの呼び出しをブロックできます。
以下のポリシー例では、指定した信頼済みアカウント以外からのピアリングアタッチメント承認をすべて拒否します。
{
"Version": "2012-10-17",
"Statement": [\
{\
"Sid": "Statement1",\
"Effect": "Deny",\
"Action": [\
"ec2:AcceptTransitGatewayPeeringAttachment"\
],\
"Resource": "*",\
"Condition": {\
"StringNotEquals": {\
"aws:PrincipalAccount": "339712835926"\
}\
}\
}\
]
}
組織全体を守りたい場合は、組織IDを指定してポリシーを拡張できます。
"Version": "2012-10-17",
"Statement": [\
{\
"Sid": "Statement1",\
"Effect": "Deny",\
"Action": [\
"ec2:AcceptTransitGatewayPeeringAttachment"\
],\
"Resource": "*",\
"Condition": {\
"StringNotEquals": {\
"aws:PrincipalOrgID": "o-xxxxxxxxxxx"\
}\
}\
}\
]
}
これらのポリシーを適用しておけば、認可されていないアカウントがTransit Gatewayピアリングアタッチメントを承認しようとしてもエラーとなります。
ソースアカウントで拒否された画面
本件は脆弱性を発見した2024年7月25日にAWSへ報告し、2024年8月7日に修正が完了しています。
DoiTは、クラウドを活用する組織がクラウドを正しく理解し使いこなすことで、事業成長を加速できるよう支援しています。インテリジェントなテクノロジーに、比類なきコンサルティング、24時間365日のサポート、トレーニングを組み合わせ、クラウドの課題解決、ナレッジの蓄積、イノベーションの加速をご支援します。クラウド活用に関するご相談は、お気軽にお問い合わせください。