こんにちは！クラウドインフラやサーバーのセキュリティを担当するようになると、避けて通れないのが「他のシステムや外部の会社とどうやって安全に連携するか」という問題ですよね。
特にAWSなどのクラウドを使っていると、自分の家（アカウント）の庭に、別の家の人をどうやって安全に入れるかという設定に頭を悩ませることがよくあります。
今回は、セキュリティの世界でよく耳にする「クロスアカウントアクセスにおける信頼関係の厳格化」、そしてその決定打となる「External ID（外部ID）」について、難しい専門用語をできるだけ噛み砕いて、身近な防犯の仕組みに例えながら一歩ずつ解説していきますね！
—
1. 身近な防犯で考える「クロスアカウントアクセス」と「合鍵」の危険性
まずは、クラウドの世界を「一軒家」に例えてみましょう。
あなたはある会社のシステムという「大きなお家」を管理しています。そのお家のなかには、大切なデータやサーバーという「金庫」がありますよね。
普段はあなたや仲間（同じアカウント内のメンバー）だけがその家に出入りしていますが、時々こんな状況がやってきます。
「外部のセキュリティ会社に、うちのサーバーの点検をしてもらいたい」
「別の部署が管理しているシステムから、うちのデータにアクセスさせたい」
こんな時、あなたはどうしますか？
わざわざ相手のために新しい部屋を作るのは面倒ですし、かといって、あなた自身の合鍵をそのまま渡してしまうのは、泥棒に「どうぞ入ってください」と言っているようなもので、猛烈に危ないですよね。
クラウドの世界（AWSなど）でも全く同じです。
自分とは違う、まったく別の会社や別チームの「外部アカウント」に対して、「うちのリソースを触ってもいいよ」と許可を与えることをクロスアカウントアクセスと呼びます。
ここで安易に「誰でもうちに入れるようにしちゃえ」と設定してしまうと、セキュリティの網の目をかいくぐって悪意ある攻撃者に侵入され、家中の財産をごっそり持ち去られてしまうリスク（権限昇格や不正アクセスのリスク）が発生してしまうのです。
—
2. 攻撃者が狙う盲点：「良かれと思って設定したガバガバな信頼ポリシー」
ここで、攻撃者がどのようにしてあなたのクラウド環境を乗っ取るのか、その手口の裏側を少しだけ覗いてみましょう。
クラウドの設定ファイルには、「信頼ポリシー（Trust Policy）」や「リソースベースポリシー」と呼ばれる、「誰にこの部屋の鍵を渡すか」を書く場所があります。
例えば、次のような設定を見たことはありませんか？
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole"
}
]
}一見すると、「123456789012という外部アカウントからのアクセスを許可しているだけだから安全そう」に見えますよね。
ですが、ここにセキュリティの大きな盲点（落とし穴）があります。
もし、この 123456789012 という「外部の協力会社のアカウント」自体が、もし万が一、サイバー攻撃者にハッキングされて乗っ取られてしまったらどうなるでしょうか？
攻撃者はその外部アカウントを踏み台にして、あなたのお家にスルスルと入り込めてしまいます。これが、信頼ポリシーを最小限に絞っていないことで起こる最悪のシナリオです。
「うちは信頼できる取引先だから大丈夫！」と思っていても、その取引先のセキュリティが破られた瞬間に、連鎖的にあなたのお家まで全滅してしまう……これが、現場で恐れられている「クロスアカウント経由の不正アクセス」の正体です。
—
3. 「不法侵入（混乱した deputies 問題）」を防ぐ最強の切り札：External ID
では、外部からのアクセスを安全にしつつ、こうしたリスクを完全にシャットアウトするにはどうすればよいのでしょうか？
そこで登場するのが、今回の主役であるExternal ID（外部ID）です。
また例え話をさせてください。
あなたはマンションの管理人をしています。ある日、宅配業者を名乗る人がやってきて、「〇〇さんのお部屋の荷物を回収しに来ました。合鍵を貸してください」と言いました。
管理人は相手の制服を見て本物だと思い、鍵を渡そうとします。
しかし、よく考えてみてください。その業者が「本当に〇〇さんから頼まれた人」なのか、それとも「制服を着ただけの詐欺師」なのか、見た目だけでは判断できませんよね。
ここで、〇〇さんが事前に管理人に対して、こう伝えておいたらどうでしょう？
「私から頼んだ業者には、必ず『ひまわり42』という合い言葉を伝えさせます。その合い言葉を言わない限り、絶対に部屋の鍵を渡さないでください！」
この「合い言葉」こそが、AWSなどのクラウドにおけるExternal IDの正体です。
External IDの仕組み
外部のサービスや別企業（SaaSベンダーなど）にあなたのアカウントへのアクセスを許可する際、単に「相手のアカウントIDだからOK」とするのではなく、「お互いにしか分からない秘密の合い言葉（External ID）」を合意しておきます。
実際にアクセスが要求されたとき、クラウド側は次のようにチェックします。
1. 「アクセスしてきた相手のIDは正しいか？」
2. 「相手は正しい『External ID（合い言葉）』を持っているか？」
この2つが両方揃ったとき初めて、一時的な通行証（権限）が発行されます。仮に相手のアカウントが乗っ取られていたとしても、この「合い言葉」を知らなければ、あなたのお家には一歩も入れないというわけです。
—
4. 実践！信頼ポリシーとExternal IDの設定例
それでは、実際にインフラやクラウドを構築する際、どのように設定すればよいのかを見ていきましょう。
今回は、AWSのIAMロール（一時的に引き受ける権限のセット）に設定する、安全な信頼ポリシーのサンプルコードをご紹介します。
ご自身のプロジェクトで設定する際は、プレースホルダー部分をご自身の環境に合わせて書き換えてみてくださいね。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SecureCrossAccountAccessWithExternalID",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
/* ↑ 信頼する外部パートナー（または別部署）のAWSアカウントIDを指定します */
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "HereIsYourSecretExternalId12345"
/* ↑ ここが「合い言葉（External ID）」です！外部ベンダーと事前に安全な方法で共有し、一致を強制します */
}
}
}
]
}設定時のポイント
Principalには、アクセスを許可する「最小限の相手」を指定します。全体を許可する*などは絶対に指定しないようにしましょう。Condition（条件）ブロックの中にsts:ExternalIdを必ず組み込みます。これがあることで、仮に相手アカウントの権限が誤って広く公開されてしまっても、合い言葉が漏れていなければ不正アクセスを防ぐ強固な防壁となります。
—
5. まとめ：今日からできる一歩
いかがでしたでしょうか？
「クロスアカウントアクセス」や「信頼ポリシー」という言葉を聞くと、なんだか難しそう、面倒くさそうと感じてしまうかもしれませんが、本質は「誰に、どの合い言葉で、お家の鍵を渡すのかを徹底的に管理する」という、身の回りの防犯と全く同じです。
クラウドセキュリティの基本は、「性善説（みんな信用できる）」ではなく「ゼロトラスト（誰も信用せず、すべてを検証する）」の精神です。
新人エンジニアの皆さん、そして開発者の皆さんがインフラやクラウドの設定を行うときは、ぜひ次のポイントを胸に留めておいてくださいね。
1. 外部へのアクセス許可は、必要最小限の相手（Principal）だけに絞る。
2. クロスアカウントの連携には、必ず External ID（合い言葉）を設定して本人確認を厳格化する。
一つひとつの丁寧な設定の積み重ねが、あなた自身と、あなたが守るシステムをサイバー攻撃から救う最大の盾になります。
一歩ずつ、安全で堅牢なシステムづくりを楽しんでいきましょう！
コメント