🏢 会社の入館証システムで例えると超わかりやすい!
SAMLフェデレーション = 外部の身分証明書で会社に入るシステム
社員証(AWS IAMユーザー)を持っていなくても、
信頼された外部機関が発行した身分証明書
で入館できる仕組みです。
でも、その信頼の証である
「署名証明書」には有効期限
があります。
期限切れになる前に、
正しい順番で
更新しないと...😱
全員が会社に入れなくなってしまいます!
🎭 入館証システムで理解するSAML認証
Identity Provider(IdP)
= 身分証明発行機関
市役所や運転免許センターのような 「公的な身分証明書を発行する機関」
• Okta、Azure AD、Google Workspaceなど
• ユーザーの認証を行う
• 「この人は本人ですよ」という証明書(SAMLアサーション)を発行
• 署名証明書で「偽造防止のハンコ」を押す
市役所の公印のようなもの。
「この証明書は確かにうちが発行しました」という証拠
Service Provider(SP)
= 入館を許可する会社
あなたが入りたい 「会社のビル」 (AWS)
• AWS = Service Provider
• IAM IDプロバイダー = 「信頼する発行機関のリスト」
• 提示された証明書が本物か確認
• 登録された公印(証明書)と照合
警備室に掲示された「信頼できる発行機関一覧」と「その公印サンプル」
ここに登録されていないと入れない!
🔄 SAML認証の流れ(入館の流れ)
ユーザー
「AWSにログインしたい」
IdP(Oktaなど)
「この人は本人です」
署名証明書で署名
AWS(IAM)
「署名を確認...OK!」
アクセス許可
📚 3つの重要な登場人物
署名証明書
(Signing Certificate)
IdPが発行するSAMLアサーション(「この人は本人です」という証明)に 電子署名 を付けるための鍵
例えるなら:
市役所の公印。これがないと証明書は偽物扱いされる
有効期限:
通常1〜3年。期限切れ=公印が無効になる
メタデータ
(Metadata XML)
IdPの情報をまとめた設定ファイル。署名証明書も含まれる
例えるなら:
「この発行機関の情報一式」
• 機関名
• 所在地(エンドポイントURL)
• 公印サンプル(証明書)
形式:
XML形式のファイル
IAM IDプロバイダー
(Identity Provider)
AWSが「このIdPを信頼する」という設定。メタデータを登録する場所
例えるなら:
会社の警備室にある「信頼できる発行機関リスト」
重要ポイント:
ここに登録された証明書と、持ってきた証明書の署名が一致しないと入れない!
❌ やってはいけない!間違った更新手順
「新しいのに変えるから古いのは消そう」
「よし、新しい証明書で署名するぞ」
「あ、AWS側も更新しなきゃ」
💀 結果:全ユーザーがログインできなくなる!
ステップ1と2の間で
「署名と登録証明書が一致しない」状態
が発生!
IdPは新しい証明書で署名 → AWSは古い証明書しか知らない → 認証失敗 😱
✅ 正しい証明書ローテーション手順
この時点では、まだ古い証明書で署名を続けます。
市役所「新しい公印を作りました。でも古い公印もまだ使えます」
このメタデータには 新旧両方の証明書 が含まれています。
市役所「新旧両方の公印サンプルが載った資料をお渡しします」
これでAWSは 新旧両方の証明書 を認識できるようになります。
会社「警備室のリストを更新!新旧両方の公印を受け入れます」
AWSは新しい証明書を知っているので、認証は成功します!
市役所「これからは新しい公印で署名します」→ 会社も受け入れOK!
複数のユーザーで、複数のロールへのアクセスをテストしましょう。
• 通常ユーザーのログイン
• 管理者ユーザーのログイン
• 各IAMロールへのAssumeRole
数日〜1週間は残しておく ことを推奨します。
すぐに削除せず、しばらく様子を見てから削除する方が安全
# AWS CLI でメタデータを更新する aws iam update-saml-provider \ --saml-provider-arn "arn:aws:iam::123456789012:saml-provider/MyIdP" \ --saml-metadata-document file://new-metadata.xml # メタデータの内容を確認する aws iam get-saml-provider \ --saml-provider-arn "arn:aws:iam::123456789012:saml-provider/MyIdP" # CloudFormation での定義例 Resources: MySAMLProvider: Type: AWS::IAM::SAMLProvider Properties: Name: MyIdP SamlMetadataDocument: |
🛡️ 恒久対策:二度と慌てないために
証明書有効期限の監視
証明書の有効期限を定期的にチェックし、期限が近づいたらアラートを送信
実装方法:
• AWS Config + Lambda で定期チェック
• CloudWatch Events で定期実行
• 外部監視ツール(Datadog等)
• IdP側の通知機能を活用
運用手順書の整備
証明書ローテーションの手順を文書化し、誰でも実行できるようにする
含めるべき内容:
• 正しい手順(順番が重要!)
• スクリーンショット付きの操作手順
• ロールバック手順
• 確認項目チェックリスト
自動化の導入
証明書ローテーションの一部または全部を自動化する
自動化できる部分:
• メタデータのダウンロード
• IAM IDプロバイダーの更新
• 動作確認テスト
• Slack/Teams通知
定期的なリハーサル
年に1回程度、実際に証明書ローテーションを練習する
リハーサルの内容:
• 開発/検証環境での実施
• 手順書の検証と更新
• 所要時間の計測
• 問題発生時の対応訓練
import boto3 import xml.etree.ElementTree as ET from datetime import datetime, timedelta from cryptography import x509 def check_saml_certificate_expiry(event, context): iam = boto3.client('iam') sns = boto3.client('sns') # IAM IDプロバイダーの一覧を取得 providers = iam.list_saml_providers()['SAMLProviderList'] for provider in providers: arn = provider['Arn'] metadata = iam.get_saml_provider(SAMLProviderArn=arn) # メタデータから証明書を抽出 root = ET.fromstring(metadata['SAMLMetadataDocument']) certs = root.findall('.//{http://www.w3.org/2000/09/xmldsig#}X509Certificate') for cert_elem in certs: cert_data = cert_elem.text cert = x509.load_pem_x509_certificate( f"-----BEGIN CERTIFICATE-----\n{cert_data}\n-----END CERTIFICATE-----".encode() ) # 有効期限を確認(60日前にアラート) days_until_expiry = (cert.not_valid_after - datetime.utcnow()).days if days_until_expiry < 60: sns.publish( TopicArn='arn:aws:sns:ap-northeast-1:123456789012:alerts', Subject=f'⚠️ SAML証明書が{days_until_expiry}日後に期限切れ', Message=f'Provider: {arn}\n期限: {cert.not_valid_after}' )
✅ 証明書ローテーション チェックリスト
📋 事前準備
🔄 実行後の確認
❓ よくある質問(FAQ)
• ブラウザキャッシュ :古いSAMLレスポンスがキャッシュされている可能性。シークレットウィンドウで試す
• IAMロールの信頼ポリシー :特定のロールだけ問題がある場合は、そのロールの信頼ポリシーを確認
• CloudTrailログ :
AssumeRoleWithSAML
イベントでエラー内容を確認
2. 古い証明書は急いで消さない: 動作確認が完了するまで古い証明書は残しておく
3. 複数アカウントは全て更新: 一つでも漏れると、そのアカウントへのアクセスが不能に
4. 本番前にテスト: 可能であれば、開発/検証環境で先に試す
可能であれば3年以上の有効期間を設定。ローテーション頻度を減らせる。
2. カレンダーリマインダーを設定:
証明書発行時に、有効期限の90日前にリマインダーを設定しておく。
3. Infrastructure as Codeで管理:
TerraformやCloudFormationでIAM IDプロバイダーを管理。変更履歴が追跡可能に。
4. 複数人でのダブルチェック:
重要な変更は二人以上で確認。手順の見落としを防止。
5. ロールバック計画を常に用意:
古いメタデータのバックアップを取り、いつでも戻せる状態にしておく。
🎓 まとめ
🔐 SAML証明書ローテーション = 公印の更新
正しい順番で更新すれば、ダウンタイムゼロで安全に実施できます!
AWS先 → IdP後
の順番を絶対に守りましょう✨
IdPで新証明書を
追加
(古いのは残す)
新メタデータを
先にAWSへ
アップロード
最後にIdPで
新証明書を有効化
確認後に古いのを削除
🛡️ 恒久対策も忘れずに!
✅ 有効期限の監視アラート設定
✅ 運用手順書の整備
✅ 可能な範囲での自動化
✅ 定期的なリハーサル
証明書ローテーションは「正しい順番」さえ守れば怖くない!
このガイドを参考に、安全に更新を実施してください🎉