トップ > ガバメントクラウド > ガバメントクラウドGCAS移行に備えAWS IAM Identity Centerを理解する

ガバメントクラウドGCAS移行に備えAWS IAM Identity Centerを理解する

ガバメントクラウド AWS IAM Identity Center
記事タイトルとURLをコピーする

こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。

仕事柄デジタル庁のホームぺージを見る機会が多いのですが、個人的な所感でレイアウトがシンプルで見やすいうえに先進的・未来的でカッコいいなと思っていました。文字フォントはオープンソース書体であるGoogle Noto Sans なのだそうです。Apache License 2.0 のライセンスルールのもと無償利用・再配布が認められているとのことで、弊社BLOGでも安心して表記することが出来るんですね。

www.digital.go.jp

本BLOGは 令和6年度ガバメントクラウド早期移行団体検証事業 から移行検証となった GCAS についてと、その認証統合に利用する AWS IAM Identity Center について自分の理解を整理したくまとめた内容となります。デジタル庁の資料にもキーワードとして登場する機会が多くなってきたので、これを機にお知りになりたい方にも参考になれば幸いです。

GCAS とは

GCAS とは「Government Cloud Assistant Service：ガバメントクラウド活用支援サービス」の略称となります。デジタル庁が運営するガバメントクラウドの利用者向けのサポートポータルサイトという位置づけかと思っております。本BLOG執筆時点では私もまだポータルサイトを見たことがないのですが、Google Cloud を活用しているそうで Google のホームぺージ*1では下記機能が実装されると紹介されています。

  • GCAS 機能抜粋
    1. ユーザー登録・認証
    2. 利用ガイド
    3. システム情報登録・環境払出申請
    4. ヘルプデスク・FAQ
    5. 全体 EBPM ダッシュボード

GCAS 移行における AWS IAM Identity Center の役割とは

このGCASですが、本BLOG執筆時点(2024年4月)では既にリリースされており*2 一部機能が利用可能で、今後順次 機能が拡充されるようです。その機能の中に「ガバメントクラウドの各CSP(AWS、Azure、Google Cloud、OCI...) 管理GUI(コンソール)へのSSO」があります。

  • SSOとは
    • シングルサインオン：1度のユーザー認証で複数のシステムの利用が可能になる仕組み

AWSの管理GUIにあたる AWSマネジメントコンソール にも、このSSOを行うために複数の手法が提供されてきました。GCASでは AWSマネジメントコンソールとのSSOの実現に AWS IAM Identity Center が利用されるようです。この AWS IAM Identity Center の利用により従来 AWSマネジメントコンソールのログイン認証に利用していたIAMユーザーが不要となり最終的にはガバメントクラウドではIAMユーザーの利用が廃止されます。本BLOGではこれをGCAS移行と表記します。このGCAS移行における AWS IAM Identity Center の役割をみていきたいと思います。

AWS公式ページでは下記のように紹介されています。

AWS IAM アイデンティティセンターは、AWS アプリケーションもしくは複数の AWS アカウント (またはその両方) に対するワークフォースのアクセスを管理するために推奨されるサービスです。これは、既存の ID ソースを接続したり、AWS でユーザーを作成したりするために使用できる柔軟なソリューションです。IAM アイデンティティセンターは、既存の AWS アカウントのアクセス設定とともに使用できます。

まずは AWS IAM Identity Center を利用しない運用からみていきます。AWSでは アカウント (以下AWSアカウントと記) という枠で請求や管理を区別しています。このAWSアカウント毎に管理GUIにあたる AWSマネジメントコンソール が用意されます。下記は私の個人検証環境にログインした時の画面ショットになります。

このAWSマネジメントコンソールへのログイン認証に利用されるのが IAMユーザー になります。このIAMユーザーはAWSアカウント毎に作成し、認証情報はユーザー名とパスワードで構成されます。AWSアカウントは部署や環境毎で別々で管理することが推奨される*3ので、下記の図のようになります。

この例だとSCOTTさんがお一人で複数のシステムを運用保守している状況です。認証情報が各AWSアカウント毎に違いますので、パスワードの変更やそれらを覚えておく負担が増えます。悩ましいですね。

この問題を解決するために AWS では数々の手法が提供されてきました。定番なのは「踏み台アカウント」を設けた Switch Role (ロールの切り替え) です。下記の図のようになります。

IAMユーザーは踏み台アカウントにのみ存在し、そこから各部署や環境毎のAWSアカウントへ切替て管理・保守を行うことができます。実際のAWSマネジメントコンソールでは最初の踏み台アカウントにログインしたあと右上のボタンから操作します。

多くのケースではこの踏み台アカウントでの Switch Role 方式で認証情報の乱立を防ぐことができ、運用においても問題となることはありませんでした。しかしクラウドの普及により、AWS以外のパブリッククラウド、SaaS、idp を組み合わせて利用するマルチクラウドの組織が増えてきたことで、さらなる認証情報の統一が必要となりました。こうした状況で活用するのが AWS IAM Identity Center です。踏み台アカウントのIAMユーザーではなく、AWS IAM Identity Center 内で管理するユーザー名、パスワードを用いて認証します。下記の図のようになります。

これだと踏み台アカウントでの Switch Role 方式と大きく変わってない気もします。比較すると多々メリットはあるのですがここでは割愛します。AWS IAM Identity Center でログインすると、下記の図ように従来とは異なるポータルが表示され、一覧より利用したいAWSアカウントをクリックすると次画面でそのAWSアカウントのマネジメントコンソールが表示されます。

この AWS IAM Identity Center は、先ほど記したマルチクラウド環境を想定した機能になります。他のクラウドアプリケーションとの認証統合する機能が充実しています。例えば、下記の図のように別のクラウドサービスのidp(認証)を用いてAWSマネジメントコンソールへアクセスすること可能になります。また、AWS以外のアプリケーションの認証に利用することもできます。クラウドで頻繁に利用される SAML により、このような柔軟な構成がとれるようになります。

今回ガバメントクラウド早期移行団体検証事業で移行検証が行われるGCASにおいてもSAMLが利用できますので、AWS IAM Identity Center を用いることで下記の図のようにSSO環境が実現可能となります。ガバメントクラウドのAWS以外のCSP(Azure、Google Cloud、OCI...) への認証統合も実現できます。

このGCASにはMFAデバイスを用いた多要素認証が実装されますので、結果的にAWSマネジメントコンソールへの接続にも多要素認証が伴うことになり、なりすましを防ぐことができます。これらメリットを次セクションでまとめたいと思います。

なお、AWS IAM Identity Center はデジタル庁の運営管理になりますので、地方自治体様や運用管理補助者様(ベンダー)が設定や運用保守することはありません。この認証の役割まで理解いただければ良きかと思います。より詳しくお知りになりたい方は、弊社エンジニアBLOGもご参照ください。

AWS IAM Identity Center カテゴリーの記事一覧 - サーバーワークスエンジニアブログ

GCAS と AWS を認証統合するメリットまとめ

IAMユーザーの利用をやめて、GCAS と AWS IAM Identity Center の認証統合へ移行するメリットとしては下記になる見解です。これらが複数CSP(AWS、Azure、Google Cloud、OCI...) で統一できるのはありがたいです。

  • ログインID 認証情報の乱立防止
    • デジタル庁がGCAS上で提供するアプリケーション間でのシングルサインオンの実現
    • AWSマルチアカウント(複数テナント) での認証情報の統一
    • マルチクラウド環境下での認証情報の統一
    • セキュリティガバナンスの統一
  • なりすまし防止
    • AWS含めたガバメントクラウド各CSPの管理コンソールへのログイン時MFA(多要素認証)の強制と統一
  • AWSマネジメントコンソールへのアクセス元デバイスの特定
    • BeyondCorp Enterprise（BCE）を用いることでAWSを含めたガバメントクラウド各CSPの管理コンソールへのアクセス元デバイス制御
    • デバイス制御にはシリアル番号とIPアドレスが利用可能とのこと *4

しかしAWSではレガシーなアプリケーション等 IAMユーザーでしか実現できなかったこともあるわけで、例えばアクセスキーの利用があります。アクセスキーは漏洩するとクラウド上の操作悪用されるリスクがあることから、利用避けることが推奨されてきました。ガバメントクラウドでもその考えは踏襲されていますが、アプリケーション互換等やむを得ない場合は、届け出をすることで審査妥当と判断された限りで利用が認められるとあります。*5

高いセキュリティは時として過去資産継承の制約となりますが、ガバメントクラウドが個別事情にも配慮がある点は好印象でした。もちろんアクセスキーの利用は推奨されませんので、アプリケーション開発者様やサービスプロバイダー様には代替案への移行を強く推奨いたします。

IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management

所感

いかがでしたでしょうか。デジタル庁のGCASガイドによると、IAMユーザーの廃止と GCASアカウントへの切替は令和6年12月までに完了する必要があると記載されています。早期移行団体検証事業で既にガバメントクラウドを利用開始されている地方自治体様は、デジタル庁からの指針に基づきGCASへの移行対応を行う必要があります。しかし、AWS や Google Cloud の専門用語が飛び交う各資料やガイドラインをみて、何から手を付けてよいか悩まれている方も多いのではと予想します。制約が多い印象を受けますが、セキュリティや運用コストの側面では多くのメリットがあるよう感じますので、ぜひクラウド利活用の推進にお役立ちいただければと思います。本BLOGの内容が皆様の少しでものご参考になれば幸いです。

本BLOGは間違いがないよう十分注意して記載しておりますが、デジタル庁の資料と差異がある場合はそちらを正としていただけますようお願いします。

*1:Google Cloud が、デジタル庁ガバメントクラウドの利用を促進するサーバレスの Web アプリケーション開発を支援 : https://cloud.google.com/blog/ja/products/gcp/application-development-to-accelerate-the-use-of-the-government-cloud/

*2:デジタル庁 - 安全・安心で強靱なデジタル基盤の実現 : https://www.digital.go.jp/policies/report-202209-202308/digital-infrastructure

*3:AWS Well-Architected Framework - SEC01-BP01 アカウントを使用してワークロードを分ける: : https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_securely_operate_multi_accounts.html

*4:本BLOG執筆時点 デジタル庁 GCASガイド - CSP管理GUIへの接続元アクセス元制御 参照

*5:本BLOG執筆時点 デジタル庁 GCASガイド - ユーザー管理方法(AWS編)

宮形純平(執筆記事の一覧)

エンタープライズクラウド部 ソリューションアーキテクト1課

好きなお酒は缶チューハイと本格焼酎