トップ > ガバメントクラウド > ガバメントクラウドAWSでの「開発・運用IAMロール」の権限制御を考える

ガバメントクラウドAWSでの「開発・運用IAMロール」の権限制御を考える

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

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

本BLOGを記載しているのは 2024年6月上旬なのですが、令和6年度ガバメントクラウド早期移行団体検証事業の第2回公募期間*1が行われている時でした。後日公募の採択結果が公開されると思いますので、皆様お住いの市町村が対象になっているか眺めるのもよいかもしれません。

今回のBLOGでは、ガバメントクラウドをご利用開始される地方自治体様よりご相談の多い「職員や運用管理補助者が利用する開発・運用IAMロールの権限制限をどのようにすればよいか」について、私なりの検討した内容をご紹介したいと思います。

本BLOGの内容は、私がこれまでの職務で得た経験に基づく個人的な考察になります。ご参考いただく際は、その方の責任の範疇でお願いいたします。 記載に間違いが無いよう注意を払っておりますが、各省庁から案内されるガイドラインや資料、AWSの公式ドキュメントと差異がある場合は、それらの資料を正とするようお願いします。

ガバメントクラウドにおける「スイッチロール」と「開発・運用IAMロール」について

「スイッチロール」についてはこれまで数多くの弊社BLOGや一般Webサイトで紹介されておりますので、説明は割愛します。 弊社の下記記事が実際の操作画面イメージもあり個人的にわかりやすいかと思います。初見の方は是非ご覧ください。

blog.serverworks.co.jp

ガバメントクラウドにおいては GCAS-SSO への移行に伴い、一般的なAWS利用におけるスイッチロールとは異なっております。下記の関係になっております。*2

この図でいう「開発・運用IAMロール」が、職員や運用管理補助者の従事者がAWSマネジメントコンソールで構築・運用保守を行う時の権限に相当します。今回はこのIAMロールの権限制御を考えます。GCAS-SSO については下記BLOGでご紹介しておりますので、あわせてご覧いただけると幸いです。

blog.serverworks.co.jp

なぜ権限制限を行う必要があるのか

なぜ権限制限を行う必要があるのかというと、ガバメントクラウド上のシステムを構築・運用保守する職員やベンダー（運用管理補助者）従事者にして欲しくない事があるからです。その最たるものが「データの外部への持ち出し」だと思われます。

地方自治体様の利用するガバメントクラウドにおいては、市町村にお住い方々のマイナンバーを含む個人情報が格納されております。これらは決して外部に漏洩してはいけませんので、職員やベンダーが故意の有無を関わらずデータを外部に持ち出せる状態にあってはいけません。

ガバメントクラウドAWSの構築・運用保守の操作は、ひとつのウェブブラウザ上で操作を完結する AWSマネジメントコンソール を利用します。AWSマネジメントコンソールはインターネットに接続して利用します。このAWSマネジメントコンソール上で個人情報が漏洩する可能性のある行為は決して行ってほしくない筈であり、コンソール上での操作の権限制限が、地方自治体様での検討テーマとなります。

IAMロールで権限制限すべき振る舞い

ここからは、私なりに考えたガバメントクラウドAWSでの「開発・運用IAMロール」に権限制御するべきと思われる行為と、その行為を禁止するための設定方法をご紹介します。そのうちの多くは IAMポリシー という IAMロールを含む IAM アイデンティティ または AWSリソースにアタッチ(割り当て)する権限セットで実現します。設定としては JSON フォーマットで記載が可能となっておりますので、そのサンプルも合わせてご紹介します。

Systems Manager Session Manager、Fleet Manager、 EC2 Instance Connect Endpoint の利用禁止

Systems Manager Session Manager、Fleet Manager、EC2 Instance Connect Endpoint は、仮想サーバーにあたる EC2 のコンソールを提供するAWS機能になります。Webベースの AWSマネジメントコンソール からサーバーのCLI、GUI が利用できますので、運用保守を容易にし、専用の保守端末やネットワークが不要となりコスト削減にも寄与します。AWSマネジメントコンソール を利用する保守端末のセキュリティ次第なところもありますが、地方自治体様毎のセキュリティポリシーによっては利用を制限されたいケースがありうると思われます。

この場合は、これらの機能利用を禁止するポリシーを「開発・運用IAMロール」に適用するべきかと思われます。

AMI、EBSスナップショット、RDS スナップショット、System Manager Document の他アカウントへの共有禁止

Amazon マシンイメージ (以下AMIと記)、Amazon Elastic Block Store (以下EBSと記)のスナップショット、Amazon RDS のスナップショット、これらはサーバーのバックアップとして一般的に利用されるAWSの機能になります。このバックアップは他のAWSアカウント向けに共有することが可能で、AWS間のデータ移行やサーバーイメージの外部公開などに利用できます。便利な機能ではありますが、マイナンバーを含む標準準拠システム等では外部へのデータ漏洩の切っ掛けになりえます。

これらの共有行為を禁止するポリシーを「開発・運用IAMロール」に適用するべきかと思われます。

NAT Gateway、Internet Gateway、VPC Peering の作成禁止

NAT Gateway、 Internet Gateway は VPC 内のプライベートネットワーク上のAWSリソースが外部インターネットへ接続する際や、逆に外部インターネット向けにプライベートネットワーク内のロードバランサーやサーバーを公開して外部からのアクセスする際などに利用します。マイナンバーを含む標準準拠システム等は外部インターネットから分離する必要があります*3。

各サーバーがインターネットと接続すると、外部へのデータ漏洩のリスクが高まりますので、NAT Gateway、Internet Gateway の作成行為を禁止するポリシーを「開発・運用IAMロール」に適用するべきかと思われます。

また、VPC Peering はVPC同士を接続する機能です。意図せずマイナンバー系ネットワーク以外と接続してしまうリスクにもなりえますので、こちらも禁止するポリシーの適用検討余地があるかと思います。

なお、実際操作で確認はしていないのですが、ガバメントクラウドAWSにおいては本番アカウントでは標準で Internet Gateway の作成が禁止されており、それ以外の運用管理アカウントや検証アカウントではその制限は無いようです。ネットワーク構成次第ですが、本番アカウント以外でも外部インターネットとの接続点は作成されるべきではないと考える地方自治体様が大半かと思います。

新たなIAMユーザーの作成禁止

IAMユーザーはAWSマネジメントコンソールへの接続にもちいるIDパスワード認証と、行う操作の範囲を定義する認可で構成されます。ガバメントクラウドにおいてはAWSマネジメントコンソールへ接続の認証にIAMユーザーは利用せず、GCAS側で提供する認証情報が用います。認証情報は必要最小限とするべきであり、また職員や運用管理補助者の従事者が新たにIAMユーザーを作成すると、なりすましや認証情報の漏洩リスクも高まります。IAMユーザー作成を禁止するポリシーを「開発・運用IAMロール」に適用するべきかと思われます。

なお、AWSでは管理ポリシーとして PowerUserAccess が提供されており、こちらにはAWSリソースの構築・運用保守を行ううえでの必要十分な権限が付与されておりますが、IAMユーザーやIAMグループに関するすべての権限が含まれておりません。PowerUserAccess を用いることでIAMユーザー作成を禁止することができます。

IAMユーザーへの アクセスキー、シークレットキーの設定禁止

IAMユーザーにアクセスキー、シークレットキーを設定することで、外部クラウドやオンプレミス等 AWS以外のシステムやサービスとAWS間を連携することができます。アクセスキー、シークレットキーは適切な利用においては便利ですが、外部漏洩すると乗っ取りや不正アクセスに悪用されるといったリスクがあります。

ガバメントクラウドにおいてはアクセスキー、シークレットキーの利用は原則禁止となっており*4、デジタル庁のポリシー標準で設定できないとありますので、「開発・運用IAMロール」においてもこの制限が踏襲されると思われます。

AWSマネジメントコンソール上での S3、RDS、CloudWatch 等の実データの読み取り行為禁止

S3バケット、RDS は標準準拠システム等でデータやログの格納に利用することが多いと思われます。また CloudWatch Logs もログの格納に利用されます。注意が必要なのが、AWSマネジメントコンソールにはこれらAWSサービス、リソース上のデータを開いたりダウンロードしたりする機能が備わっていることです。個人情報を含むデータを閲覧する職務権限が与えられない職員や運用管理補助者が、意図せずデータを入手してしまわないよう「開発・運用IAMロール」においては行為を禁止すべきかと思います。

ガバメントクラウドにおいては標準で AWSマネジメントコンソール上での S3、RDS、CloudWatch 等の実データの読み取りが行えないよう制限が掛かっているとの情報があります。「開発・運用IAMロール」においてもこの制限が踏襲されると思われますが、最新の仕様についてはデジタル庁より案内される資料をご覧ください。

コンソール上からの Amazon RDS への Export 行為禁止

Amazon RDS はAWSが提供するリレーショナルデータベースのマネージドサービスです。OSを利用者が運用保守する必要がないことから、AWSマネジメントコンソールから複数のデータベース操作が行えるようになっています。この操作では Export (データベースによってはダンプ、シリアライズ等と表現)も可能となります。Amazon RDS は標準準拠システム等のデータを格納していますので個人情報を含むことが考えられます。Exportする行為はデータの閲覧と同様と見なされますので、職務権限が与えられない職員や運用管理補助者が不用意にデータ持ち出しをしないよう「開発・運用IAMロール」においてこれら行為を禁止すべきかと思います。

ガバメントクラウドにおいては標準では AWSマネジメントコンソールから RDS への Export行為 に制限が掛かっているとの情報があります。「開発・運用IAMロール」においてもこの制限が踏襲されると思われますが、最新の仕様についてはデジタル庁より案内される資料をご覧ください。

CloudShell の利用禁止

CloudShell を利用することで、AWSマネジメントコンソール上から Webブラウザを用いてCLIでAWSサービスやリソースを制御することができます。この CloudShell ですが、EC2のOSリモート接続、RDSのデータベース接続、S3バケットの照会といった行為がCLI上で出来てしまいます。意図せず標準準拠システム等のデータがAWSマネジメントコンソール上で表示できてしまう可能性があることから「開発・運用IAMロール」において利用を禁止すべきかと思います。

ガバメントクラウドにおいては標準では AWSマネジメントコンソールから CloudShell が起動できないよう制限が掛かっているとの情報があります。「開発・運用IAMロール」においてもこの制限が踏襲されると思われますが、最新の仕様についてはデジタル庁より案内される資料をご覧ください。

まとめ

いかがでしたでしょうか。AWS等のパブリッククラウドはインターネット上で利用するイメージから、機密性の高いデータを格納することをご心配される方が多いと思います。本BLOGでご紹介した振る舞いを「開発・運用IAMロール」で制限することで、意図せずデータを外部へ持ち出しされるリスクを大幅に抑制できることがお分かりいただけたかと思います。本BLOGの内容が皆様の少しでものご参考になれば幸いです。

*1:令和6年度ガバメントクラウド早期移行団体検証事業：https://www.digital.go.jp/news/413c222d-5837-4017-b344-6d3e54d15405

*2:デジタル庁 GCASガイド：ホームガバメントクラウド AWS 利用ガイドGCAS-SSOへの移行に伴う対応(AWS編)

*3:2023年9月 - 地方公共団体情報システム標準化基本方針 : https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/f6ea9ca6/20230908_policies_local_governments_outline_03.pdf

*4:デジタル庁 GCASガイド：ガバメントクラウド＞AWS利用ガイド＞ユーザー管理方法(AWS編)

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

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

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

"; doc.innerHTML = entry_notice + doc.innerHTML; }
' } }) e.innerHTML = codeBlock; });