こんにちは！インフラやセキュリティの現場を渡り歩いてきたホワイトハッカーの私ですが、今回は新人のIT担当者や、これからセキュリティに向き合う開発者のみなさんに向けて、とっても大切なテーマをお話ししますね。
複数のクラウド（AWS、Azure、GCPなど）を同時に使う「マルチクラウド環境」、最近は本当によく見かけるようになりましたよね。でも、便利になる一方で「あっちのクラウドにはこのID、こっちのクラウドには別のID……」と管理する鍵が増えすぎて、頭が痛くなっていませんか？
今回は、そんなバラバラな鍵をスマートに1つにまとめる「IDフェデレーション」と、そこに潜むセキュリティの罠について、身近な例えを交えながら一歩ずつ優しく解きほぐしていきましょう！
—
1. 家の鍵で考えてみよう！「マルチクラウド」と「IDフェデレーション」
みなさんの「家（会社組織）」を想像してみてください。
昔は、会社用のサーバー室という「1つの部屋」だけに鍵をかければよかったのですが、今はどうでしょう？
- 「書類の保管庫」はA社が管理するトランクルーム（AWS）
- 「顧客データの管理場所」はB社が管理する倉庫（Azure）
- 「メールやチャット」はC社が提供するビル（Google Cloud）
このように、あちこちに大事な荷物を預けるのが「マルチクラウド環境」です。
ここで問題になるのが「鍵の持ちすぎ問題」です。
新人のスタッフが入社するたびに、A社の鍵を作り、B社の鍵を作り、C社の鍵を作る……。これでは管理が大変ですよね。それに、もしスタッフが会社を辞めたとき、「全部のクラウドからその人の鍵を回収し忘れた！」なんてことが起きたらどうなるでしょうか？辞めた元スタッフが、いつでもこっそり倉庫に入り放題になってしまいますよね。これが、サイバー攻撃者が一番狙う「管理の隙（盲点）」なんです。
そこで登場するのが「IDフェデレーション（身元証明の共通化）」です。
これは、いわば「信頼できる身分証明書（パスポート）を1つだけ持っておき、どの倉庫に行くときもそのパスポートを見せれば顔パスで入れる仕組み」のことになります。
これなら、スタッフが会社を辞めたときに「大元のパスポート（社内のMicrosoft 365やGoogle WorkspaceなどのID）」を1つ無効化するだけで、すべてのクラウドの鍵が一気に閉まります。めちゃくちゃ安全でスマートだと思いませんか？
—
2. 攻撃者はどうやってその「パスポート」を狙うのか？
「じゃあ、パスポートを1つにまとめれば完璧だね！」と思ったそこのあなた。ちょっと待ってくださいね。
セキュリティの世界はそんなに甘くありません。「1つの鍵で全部が開く」ということは、もしその鍵が盗まれたときのリスクが、文字通り「ケタ違いに大きく」なるということです。
攻撃者は、私たちが使っている「パスポートのやり取り（SAMLやOIDCという仕組み）」の隙を常に狙っています。
よくあるサイバー攻撃のシナリオ
1. 攻撃者は、社員のパソコンにこっそりウイルスを送り込むか、巧妙な偽メール（フィッシング）で社員のパスワードを盗み出します。
2. 攻撃者は盗んだパスワードを使って、大元の身分証明書の発行元（IdP：Identity Providerと呼ばれるシステム）にログインします。
3. IdPは「おっ、本物の社員さんですね！では各クラウドへの通行手形を発行します」と、「SAMLアサーション」というデジタル証明書を攻撃者に渡しちゃいます。
4. 攻撃者はその通行手形を使って、AWSやAzureの重要なデータをごっそり持ち逃げします。
そう、クラウド側のセキュリティをいくらガチガチに固めていても、大元の「身分証明書のやり取り」に不備があると、いとも簡単に突破されてしまうんです。
—
3. 実践！安全なSAML/OIDCフェデレーションの設定を覗いてみよう
では、現場のエンジニアたちはどうやってこのフェデレーションを守っているのでしょうか？
百聞は一見に如かず、今回はSAML（XMLベースの認証連携の仕組み）を使った設定の一部を、初心者向けに優しく解説しながら見ていきましょう。
例えば、クラウドサービス（AWSなど）に「この身分証明書（IdP）を発行した相手以外からの手形は信用しませんよ」と教える設定ファイル（メタデータ）のイメージです。
<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://login.example.com/company-idp">
<!--
ここがポイント！
「うちの会社（example.com）の公式な身分証明書発行所（IdP）はこのサーバーですよ」
という大元の証明書（信頼の根拠）を定義しています。
-->
<IDPSSODescriptor WantAuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<!-- 偽物の手形を作られないようにするための暗号化鍵（署名用証明書） -->
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>
MIIC8DCCAdigAwIBAgIQ...（中略：ここに本物の電子証明書が入ります）
</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<!-- 認証成功したあとに、ユーザーをどこに送り返すかの出口設定 -->
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://login.example.com/sso/saml"/>
</IDPSSODescriptor>
</EntityDescriptor>ここで絶対におさえてほしいチェックポイント！
上記のコードの中にある WantAuthnRequestsSigned="true" という設定、見えますか？
これ、「クラウド側から送るリクエストにも、ちゃんとした電子署名（ハンコ）をつけてね」というめちゃくちゃ大事な設定なんです。
もしここが false（ハンコなし）になっていると、途中でワルモノが通信を勝手に書き換えて、別の権限（例えば、一般社員なのに管理者権限！）に変えてしまう「中間者攻撃（Man-in-the-Middle Attack）」という恐ろしい攻撃を許してしまいます。「設定をサボらないこと」、これが現場での鉄則です！
—
4. 現場のホワイトハッカーが教える、今日からできる防犯対策
最後に、インフラの現場で私たちが必ず実装している「現実的な防犯対策」を3つだけお伝えしますね。難しくないので、ぜひ明日の業務から意識してみてください。
1. 「多要素認証（MFA）」は絶対の義務にする
パスワードがもし漏れても、スマホのアプリに飛んでくる通知（数字の入力や指紋認証など）がなければログインできない仕組みを必ず入れましょう。「鍵＋防犯カメラのダブルチェック」にするイメージです。
2. 「最小権限の原則」を徹底する
フェデレーションでログインしたあとに、その人が「何でもできる神様（Administrator）権限」になっていませんか？ 普段の作業は必要最小限の権限（一般ユーザー）にしておき、本当に必要なときだけ一時的に権限を昇格させる仕組み（JITアクセスなど）を取り入れましょう。
3. 使っていない連携はすぐに消す
プロジェクトが終わったあとも放置されている古いクラウド連携やテスト用のID設定は、いわば「裏口の鍵」です。定期的に棚卸しをして、不要になったものは容赦なく削除する勇気を持ちましょう。
—
セキュリティの世界は一見すると複雑で難しく感じますが、本質は私たちが日常生活でやっている「戸締まり」や「身元確認」とまったく同じです。
一歩ずつ、目の前の設定の意味を理解しながら、安全で快適なクラウド環境を作っていきましょうね！それでは、また次回のセキュリティ解説でお会いしましょう。
コメント