ガバメントクラウド利用システムにおけるセキュリティ対策(共通)

本書はガバメントクラウドにおける、利用システム側の対応すべきセキュリティを理解するための文書である。本書は各CSPに共通した内容であり、CSPに特化した内容は別書となっている。本書が親となる構成のため、別書は本書を読了後に閲覧すること。また、本書ではクラウドに由来しない一般的なセキュリティ対策全般を網羅的に記載しているわけではないので注意されたい。

セキュリティ全体像

はじめに、オンプレミスとクラウドでのセキュリティの違いについて理解する必要がある。
オンプレミスでは境界型セキュリティの考え方に基づき、危険な外部から内部ネットワークへの侵入を防御することを前提とした設計が主流である。
しかし、クラウドでは外部と内部の境界があいまいであり、オンプレミスと同様の考え方だけでは不十分である。
クラウドではゼロトラストの考え方に基づき、全てのアクセスを信用しないことで脅威を防止することを前提としたセキュリティとなる。インターネットとVPCの境界など、重要なポイントに関しては、オンプレミスと同様の境界型セキュリティに基づいたセキュリティ対策を実施する。

以下にガバメントクラウドのセキュリティ全体像を示す。

図001　ガバメントクラウドのセキュリティ全体像

図で示したように、ガバメントクラウドにおけるセキュリティは、責任共有モデルにより利用システム、ガバメントクラウド管理組織、CSPの三種類に責任範囲が分割される。本書ではそのうち、「各利用システム」におけるセキュリティについて記述する。各利用システムのセキュリティは、主に以下の三点で構成される。

• ガイドに基づくシステム構成と運用で実現するセキュリティ
• テンプレート/IaCファイルを使って構築することで実現されるセキュリティ
• 払い出し時に自動的に設定される予防的・発見的統制

　

責任共有モデル

責任共有モデルとは、クラウドサービスを利用する上で、CSPと利用者がセキュリティとコンプライアンスの責任を負う範囲を定めたものである。一般的には物理サーバ、物理ストレージ、ネットワーク、マネージドサービスなどがCSPの責任範囲となり、OS、ミドルウェア、CSPが提供するサービスの設定、アンマネージドサービス上のデータなどが利用者の責任範囲となる。ただし、公共分野のシステムにおいては実際の責任の有無に関わらず、説明責任を問われる場合があることを想定しておかれたい。
以下に責任範囲の例となる図を示す。

図002　責任範囲例

図中の番号がつけられた部分が利用者の責任範囲である。
①外部から許可した通信とそれを受けるプログラム
②サービスそれ自体ではなくその設定
③環境へアクセスするデバイスや通信

ガバメントクラウドでの責任共有モデル

ガバメントクラウドにおける責任範囲は、以下の三つの範囲に分割される。

• 利用組織
  クラウドサービスを含めたインフラ構成、クラウドサービスの設定、OS、ミドルウェア、アプリケーション、データの管理など
• ガバメントクラウド
  ガードレール設定、テンプレート/IaCファイル、環境払い出しなど
• CSP
  クラウド基盤（ハードウェア、ソフトウェア、ネットワーク）、マネージドサービスなど

このうち、利用組織の責任範囲はマネージドサービスを利用することで狭めることができ、セキュリティリスクを軽減することができる。詳細については責任共有モデルにおける範囲の限定を参照。

図003　ガバメントクラウドでの責任共有モデル

ガイドに基づくシステム構成と運用で実現するセキュリティ

ガバメントクラウドが本格的な最初のクラウドサービス利用であるシステムの場合、経験則による対応が困難であったり、クラウド技術の十分な教育や運用手順の標準化が図られていない、といった課題を持っている場合がある。本項では、そういったシステムの担当者向けに、適切なセキュリティレベルを備えたシステム構築と運用の参考となる内容を記述する。

設計方針

　

責任共有モデルにおける範囲の限定

システム構築に仮想サーバーサービスを利用する場合、「図003　ガバメントクラウドでの責任共有モデル」で示したように、OS、ミドルウェア、ネットワーク構成などは利用者側の責任範囲となる。仮想サーバーサービスの代わりにマネージドサービスを利用した場合、前述の責任範囲の大部分、もしくは全てがCSPの責任範囲となり、この部分のセキュリティ対策が不要となる。
ただし、マネージドサービスであっても、サービスの設定内容は利用者側の責任となることには留意する。

セキュリティ対応策

ガバメントクラウド上のシステムで考えるべき認証の例示

ガバメントクラウド上で稼働するシステムの認証については、各組織の準拠すべきポリシーに従ってその実現方式を定義し実装を行う。認証方式の定義の際には、米国立標準技術研究所（NIST）が定義する「デジタルアイデンティティガイドライン NIST SP
800-63の最新版や、内閣サイバーセキュリティセンター（NISC）が定義するガイドを参照できる。ここでは、ガバメントクラウドチームによる運用管理において定義している認証の基本原則を、利用システムでも参照できる情報として、人に対する認証とシステムに対する認証の両方で4パターンずつ紹介する。今後のクラウド機能の拡充や環境の変化に応じて、随時参照できるパターンを増やしていく。

ガバメントクラウドとしての認証の基本原則の例示

ガバメントクラウドの運用管理はこの原則に従って認証を実装している。

1. 1つの実体につき1つのID
   - 1つの実体（人もしくはシステム、サービス）につき1つのIDを割り当てる
   - 原則、IDの共有は禁止する
2. 人の認証では、パスワード＋多要素認証を利用
   - 人の認証では、パスワード桁数などのポリシーに従ったパスワードと、原則として異なる属性を持つ情報を認証のシークレットとして多要素認証を行う
3. システム間の認証では、一時トークンを利用
   - システム間（サービス間）での認証では、比較的短い有効期限をつけて一時的に発行された一時トークンをシークレットとして認証を行う
4. IDに付与する権限は最小とする
   - IDはアクセス可能なサービスや機能を必要最小限に限定する
   - 用途（システムやプログラム、ストレージ領域等）ごとにIDと権限を分ける
5. 認証情報は平文で書かない
   - パスワードやトークン等のシークレットをプログラムコードやファイルに直接平文で書かない（暗号化したり信頼できるシークレット管理の仕組みを使う）
6. IDのログを記録し確認する
   - どのIDがどこにアクセスし何をしたかをログとして記録する
   - ログに対して定期的に不正がないか確認する（特に権限の強いID等に対して行う）
7. IDの棚卸を行う
   - IDがどれくらい発行されており、どのくらい使われているのか把握し管理する
   - 使われていないIDや長期間利用休止中のIDは無効化または削除する
8. クラウド利用のベストプラクティスに従う
   - クラウド事業者各社が出しているID管理や認証のベストプラクティスに従って運用を行う

認証パターン

1. 人の認証

利用システム側のアプリケーションにおけるユーザ認証は、準拠すべきポリシーや原則に従いつつ、実装方式によって実現できる
方式を利用システム側で定義する。典型的には、図の1-1.のようになると考える。
利用システムでクラウド事業者のクラウドサービスをそのままアプリケーションとしてユーザからアクセスさせたい場合は、認証
の実装方式について留意点がある。3つのケース（図1-2.〜図1-4.）に分類して定義する。

図1-2. クラウド管理画面利用時の認証

アプリケーションの一部としてクラウド管理画面を使うことは原則避ける（*1）。一方で、クラウドインフラ運用のためにクラウ
ド管理画面を使う場合は、ガバメントクラウドのGCAS認証に従う。

*1 権限の設定次第ではあるものの、クラウドインフラを操作できる画面を使って業務アプリケーションを動作させると、職務分離（権限の分離）や日々の業務の中でインフラ構成がリスクにさらされるという観点で避けた方が望ましい。

図1-3. 外部IdPと連携可能なクラウドサービスでの認証

クラウドサービスによってはユーザー向け機能を独自画面やインタフェースで用意し、外部のIdP(Identity Provider)と認証連携可
能である。このようなクラウドサービスを使う場合は、典型パターン（1-1.）と同じく組織の認証システムを外部IdPとして認証を
任せ、複数のアプリケーションへのシングルサインオンを実現できる。

図1-4. 一時トークンを利用するクラウドサービスでの認証

クラウドサービスでは、そのクラウドが生成する一時トークンを使った認証機能を提供している場合がある。その場合、GCASに
よるシングルサインオン後のクラウド管理画面もしくは機能から一時トークン取得してクラウドサービスに対する認証を行う。

図004-1:ガバメントクラウドでの認証パターン（1. 人の認証）

2. システムの認証

システム内での認証の典型的なケースとして、アプリケーションサーバからのデータベース（やストレージ）の認証がある（図2-1.）。データベース（やストレージ）への認証情報は秘匿情報として厳重に取り扱う必要があるため、クラウドサービスのシークレット管理サービスに保管する等して、プログラムコードに直接書いたりOSファイルに平文で書いたりしないようにする（図2-1.の案1）。もしくは、データを保管するデータベースやストレージが対応している場合は、クラウドが提供する、サービスに紐づけた一時トークン発行機能を利用してアクセスする。

システム間の認証では、同一クラウド内（図2-2.）、異なるクラウド間（図2-3.）、オンプレミスとクラウド間（図2-4.）のケースで実装方式を定義する。すべてのケースで一時トークンを使ったクラウドサービスの認証を実現する。

図2-2. 同一クラウド内では、クラウドの機能として用意されている、サービスに紐づけた一時トークンが使えるため、これを使って認証を行う。これにより、シークレットデータをどこにも保管せず、ユーザの手にも渡らないかたちで安全に認証が行える。

図2-3. 異なるクラウド間では、OIDCによるIDフェデレーションと一時トークンを組み合わせてのクラウドサービス連携を行う（*2）。これにより、（半）永続的なシークレットデータを発生させることなくクラウドサービス間での認証が可能となる。一部のクラウドサービスでは利用できないこともあるため、事前のクラウドサービス間の組み合わせでは実現可否の確認を行う必要がある。その場合は、図2-4.の構成に近づき、認証システム（IdP）を構築する方式を用意する必要がある。

*2 たとえば、AWSのAssumeRoleWithWebIdentity機能、Google CloudのWorkload Identity Federation、AzureのFederated identity credentials、OCIのOCI IAM Workload Identity Federationがこれに対応する

図2-4. オンプレミスとクラウドの間（図2-4.）では、クラウドの一時トークンを発行するための認証サーバ（認証アプリ）をOAuth M2M認証などの仕組みを使って開発して用意するか、クラウドサービスの一時トークンを使ったオンプレミスサーバとのファイル連携機能を利用する（*3）。

*3 AWSのssm agent機能やIAM Roles Anywhere、OCIのOIC agentがこれに対応する

ガバメントクラウドでの認証パターン（2. システムの認証）

3. システム間データ連携

システム間でデータ連携を行う場合は、まずはAPIによるデータ連携を検討する。ここでのAPIは、RESTful APIやGraphQL、gRPC等のHTTP(S)ベースの現代的なAPIを指す。

クラウドサービスのAPIを直接使ってデータ連携する場合も、あるいは、API Gatewayを立ててそのAPI経由でデータ連携する場合も、上記の認証パターンが利用できる。他システムへのデータ連携が必要な場合は、外向けのAPIを用意する。

もしファイルでの連携が必要な場合は、オブジェクトストレージのサービスを使ってAPIでファイル連携する。この場合も上記の認証パターンが利用できる。

GCAS認証によるCSP環境へのシングルサインオン

令和6年度よりGCASではGCAS認証によるCSP環境へのシングルサインオン機能（GCAS-SSO）を展開する。これにより、GCAS認証（実態はGoogle Workspaceの認証）後、GCASアカウントのID(メールアドレス)を用いてガバメントクラウドで提供する各種サービス(CSP環境やヘルプデスクなど）へ認証の操作不要でログイン可能になる。

図003-a　GCASシングルサインオン概要

• GCASで実現するシングルサインオンの目的
  ガバメントクラウドで提供する各種サービスへのシングルサインオンの目的は以下の通り。
  • GCAS認証への統合によるGCAS提供アプリ、CSPへの認証操作省略によるユーザビリティ向上
  • GCASアカウントへの統合によるGCAS提供アプリ、CSP毎のアカウント管理負荷の軽減
  • GCAS IDに対する一元化された認証強化設定(MFA)とアクセス元制御によるセキュリティ向上
• GCAS-SSOを実現する仕組み
  GCASにおけるユーザー認証では、Google社Cloud Identityを利用している。Cloud Identity は IDaaS（Identity as a Service）ソリューションとして提供されている。ガバメントクラウドではGCASで利用しているアプリケーション、SaaS、各CSP環境とCloud IdentityをSAML規格に基づいてシングルサインオン連携を実装中である。Cloud IdentityはSAML規格において外部Identity Provider(IdP)として機能する。AWS環境では認証・アクセス権管理サービスのAWS IAM Identity CenterとSAML連携し、ユーザー情報を同期する。

図003-b　AWS環境を例としたシングルサインオンイメージ
[Googleドキュメント: Cloud Identity とは]
https://support.google.com/cloudidentity/answer/7319251?hl=jaopen_in_newOpens in new tab

• GCAS-SSOへの移行に伴う対応
  令和5年度時点でガバメントクラウドのCSP環境の利用組織は、シングルサインオン機能の実装による外部IdPの利用により、既存ユーザーアカウントアカウントからの切り替えが必要になる。詳細は各CSPの「GCAS-SSOへの移行に伴う対応」を確認すること。
• GCAS-SSO障害時の対応
  GCASにおけるユーザー認証では、Google社Cloud Identityの認証機能を利用する。Cloud Identityが障害等で利用不可な場合はGCASのシングルサインオンを介したCSP環境へのログインが不可となる。過去実績から障害が発生する率は極めて低いことがわかっている。本番リリース作業等で管理インタフェースの利用を予定していて、障害からの復旧を待てず、障害に備えて緊急アクセス用のユーザーが必要だと利用組織が判断する場合は、GCAS緊急ユーザー管理（GCAS BreakGlass）システムを用いて緊急アクセスユーザーを発行し、発行された認証情報を用いて各CSPへログインすることが可能となる。ただし、本機能が利用できないCSPについては、事前にガバメントクラウド管理組織に該当ユーザーの作成を依頼する。各CSPへの対応は、以下の通りとなる。AWS、Azure、OCIについての詳細はGCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。
  なお、Google Cloudについてはその利用がCloud Identityによる認証が前提となるため、SSOアクセス不可時(Cloud Identityアクセス不可時)にはGoogle社による復旧を待つこと。

※CSP別 GCAS-SSO障害時の対応方針

多要素認証の使用

ID、パスワードのみの認証では、攻撃者によるパスワードリスト攻撃やブルートフォース攻撃等で認証を突破される可能性が高く、認証強度として不十分である。ガバメントクラウドの利用では全利用者の多要素認証を必須とする。多要素認証とは複数の異なる認証要素を組み合わせる方式を意味し、認証要素にはID/パスワードに代表される知識属性、トークンなどの所有による所有物属性、指紋などの生体属性が挙げられる。ガバメントクラウドでは各属性の組み合わせを原則とする。多要素認証の設定対象と方式は次のとおり。

• 多要素認証の設定対象のユーザー
  ガバメントクラウドの利用における多要素認証の設定対象ユーザーは次のとおりである。CSP上に利用システム側で構築したアプリケーションの認証は利用システム側で検討する。
  • GCAS
    • GCAS利用ユーザー
  • CSP
    • AWS環境
      • デジタル庁が払い出したGCASアカウントによってのみ、各CSP環境へのアクセスが可能である。ガバメントクラウドにおいてはGCASアカウントの利用において多要素認証を行う。
    • Microsoft Azure
      • デジタル庁が払い出したGCASアカウントによってのみ、各サブスクリプションへのアクセスが可能である。ガバメントクラウドにおいてはGCASアカウントの利用において多要素認証を行う。
    • Oracle Cloud Infrastructure
      • テナンシーの初期テナント管理者ユーザー（デフォルトのIdentity Domain内に作成される）。
      • 各Identity Domain内のIAMユーザー。GCASからCSP環境へのシングルサインオン認証移行前はIdentity Domainにて利用システム側で設定する。移行後はGCAS認証の設定が優先される。
    • Google Cloud
      • Google Cloud環境はGCAS利用ユーザーと同一である。
• 多要素認証の設定と方式
  ガバメントクラウドの利用におけるユーザーの権限種別に基づき多要素認証の方式は次のとおりとする。GCASにおけるシングルサインオン機能の利用開始後は、GCASの認証で利用するGoogle Workspaceにおいて設定する。GCASのGoogle WorkspaceではGoogle Cloud Identityを認証機能として利用している。「Googleアカウントの管理」メニューから2段階認証open_in_newOpens in new tabを設定する（詳細は「ガバメントクラウド概要解説_8 利用の全体の流れopen_in_newOpens in new tab」を参照）。

　

表001 ユーザーの権限種別に基づく多要素認証方式

補足事項
①：ID、パスワードによる認証に加えて、FIDO規格準拠のハードウェアトークン方式の採用を原則とする(Google社ではセキュリティキーと表現されている)。ハードウェアトークンに関する詳細は後述する。なお、GCASの認証ではハードウェアトークンの利用を強制する制御ポリシーの適用を令和6年度7月以降に予定している。
②：セキュリティキーはGCASで用いているGoogle Workspaceがサポートする認証方式であり、①で指定したFIDO規格のハードウェアトークン以外にスマートフォンの組み込みのキー等がある。認証システムアプリにはスマートフォンで動作するGoogle Authenticator等がある。GoogleからのメッセージはGoogle社が提供するスマホアプリへの通知へのアクションによって認証する方式である。なお、ガバメントクラウドではパスキーの利用は許可していない。音声またはテキストメッセージを利用するSMS認証についても令和7年度以降に禁止予定である。詳細はGoogleヘルプを参照する。
https://support.google.com/accounts/topic/2954345?hl=ja&ref_topic=7667090&sjid=4492682044056046115-APopen_in_newOpens in new tab
令和7年度以降、セキュリティ強化のためログイン時のSMSによるワンタイムパスワード認証を利用禁止予定で検討している。現状、SMSの利用においては、SIMスワッピングなどの被害が報道されていることから該当の電話について通話または通信が確実に行えることを確認し、当該電話を本人が利用可能であることを担保する。

• 多要素認証で用いるハードウェアトークンの補足
  GCASにおいて利用可能なハードウェアトークンはFIDO（Fast Identity Online）規格をサポートしFIDOアライアンスが認定するハードウェアトークンとなる。FIDO規格にはFIDO1.0(U2F)、令和5年現在における最新のFIDO2があり、GCASの認証ではどちらも対応可能である。調達時に選択可能であれば将来的な互換性のために最新の仕様であるFIDO2をサポートするトークンを選択する。その際、FIDOの規格としてトークン内に暗号鍵を保有することから、耐タンパ性が確保され、トークン・認証情報の複製に対し強い耐性を有することを確認する。
  利用するPCに合わせてコネクターの形状を確認して選択する。また、FIDO アライアンスは、FIDO 規格に適合するすべての FIDO 認定製品open_in_newOpens in new tabのリストを公開しているので必要に応じて参照する。なお、AWSアカウントのルートユーザーなどの特権管理者の認証に用いられるハードウェアトークンは金庫などの施錠管理できる箇所に保管する。それ以外のユーザーのハードウェアトークンは第三者が入手・悪用できないよう、適切に管理すること。
  GCASが利用するGoogleにおける設定は以下のリンク先を参考に実施する。
  [Googleドキュメント：2 段階認証プロセスにセキュリティ キーを使用する]
  https://support.google.com/accounts/answer/6103523?sjid=5245628036608199608-APopen_in_newOpens in new tab)
  [Googleセキュリティキー設定画面]
  https://myaccount.google.com/signinoptions/two-step-verification?flow=sk&opendialog=addskopen_in_newOpens in new tab
  なお、ハードウェアワンタイムパスワードトークンはGCASの認証ではサポートされていないため利用不可である。一方でAWS環境におけるルートユーザーやIAMユーザーの認証はGCAS認証とは直接連携しないため、利用可能である。AWS環境でハードウェア TOTPトークンを設定する場合は、AWSとの互換性確保のため、このリンク先（OTPトークンopen_in_newOpens in new tabまたは OTPディスプレイカードopen_in_newOpens in new tab）から購入する必要がある。
  ただし、ワンタイムパスワードトークンはバッテリーで動作するため、定期的な交換や充電の運用の考慮が必要になる。

CSP管理GUIへの接続元アクセス制御

ガバメントクラウドでは、GCASの認証機能として利用しているGoogle社のCloud Identityから各CSPへシングルサインオンを行う際、アクセス元の利用端末のシリアル番号または接続元ネットワーク環境を示すグローバルIPアドレスに基づいたアクセス制御が可能である。

このアクセス元制御は、Google社が提供するChrome Enterprise Premium（CEP）（旧 BeyondCorp Enterprise（BCE））と呼ばれるツールを用いて実現する。CEPで提供されるChromeブラウザの拡張プラグインEndpoint Verification(EV)を利用することで端末のシリアル番号がCEPに連携され、アクセス制御に用いられる。

図003-C　CEPを利用したアクセス元の制御イメージ

後述の通り、CSP環境ではGCASアカウントからのシングルサインオン実装に伴い、利用システム側によるCSP環境のアクセス制御設定操作に制約が生じる場合があるため、CSP環境へのアクセス元制限を検討、実施中の利用組織は本アクセス制御方法の利用を検討する。

CEPの利用は国の行政機関/地方公共団体によって次の方針となる。

図003-D　国の行政機関および地方公共団体のガバメントクラウドにおけるアクセス元制限方針

CEPの利用が必要な組織は後述の手順に従ってライセンス利用申し込みを行い、アクセス元制御情報をガバメントクラウドチームに連携し、ツールの導入を行う。

• CEPの利用方法
  CEPは、前述のChromeブラウザの拡張プラグインEVを導入後、利用者の操作は不要である。
• CEPによるアクセス制御の仕様
  • CEPによるアクセス制御は、GCASアカウントを用いて各CSP環境へシングルサインオンする際に一律で適用される。
  • CSPにアクセスする端末シリアル番号または(グローバル)IPアドレスに基づいてアクセスを制御する。ただし、IPアドレス(CIDR表記)を申請した場合、端末シリアル番号で申請した端末に加えて、そのIPアドレスをアクセス元とする端末からのアクセスが許可される。
  • CEPライセンス有無の違いによる国の行政機関と地方公共団体のアクセス制御適用有無は以下の通り。
    • 各府省庁はCEPのライセンスが割り当てられたユーザーに対してアクセス制御が有効化される。ライセンスが割り当てられていないユーザーはアクセス制御が行われず、CSP環境へ接続元によらずアクセスできることに注意すること。
    • 地方公共団体はCEPのライセンスが割り当てられたユーザーに対してアクセス制御が有効化される。ライセンスが割り当てられていないユーザーは、CSP環境へアクセスができないことに注意すること。
  • アクセス先に対するアクセス制御は、国の行政機関または地方公共団体のガバメントクラウド利用組織全体で全CSP環境に対して一律で適用される。組織やCSP、本番環境、検証環境などの種別ごとの制御ではないことに注意する。したがって、開発環境にアクセスするユーザーのうち、テレワークを行う開発業者のみ開発環境に対してのみアクセス許可したいという対応は不可となる。ユーザー認証で制御する。
  • 端末のシリアル番号取得は以下の内容を確認して実施する。
    • WindowsOS
      • Microsoftアカウントでサインインまたは紐付けられている場合、「Microsoftアカウント」でWindows OSのシリアル番号を確認可能である。「Microsoftアカウント」にサインイン後、デバイスの項目にて確認したいPCにある「詳細を表示」を選択する。デバイスの情報から「シリアル番号」を確認する。
      • コマンドプロンプトまたはPowerShellにて以下のコマンドでWindows11のシリアル番号を確認する。
        wmic bios get serialnumber
    • macOS
      Apple社の「Mac のモデル名とシリアル番号を調べる」を参照する。
      https://support.apple.com/ja-jp/HT201581open_in_newOpens in new tab
• CEP利用の端末前提条件
  • CEP利用においてEVの導入に関する端末の前提条件は次の通り。なお、接続元のグローバルIPアドレスによるアクセス制御のみを希望する場合、EVの導入は不要である。また、各府省での一部で利用されているGSS端末におけるEVの導入は不可である。
    • Chromeブラウザおよび拡張プラグインインストール権限保有
    • Googleサービスの名前解決
• GCASシングルサインオン利用上の制約とCEPの利用
  AWSやAzure、GoogleではGCASアカウントからのシングルサインオン実装に伴い、利用システム側主体のCSP環境における接続元IPアドレス等のアクセス制御操作に制約が生じる場合があるため、各CSPのガイド（「セキュリティ - CSP管理GUIへの接続元アクセス制御」項）を参照する。必要に応じてCEPの利用を申請する。
• CEPの利用手続き
  CEPの利用及びライセンスの希望組織はメンバー限定ページにある「ガバメントクラウド手続き概要」を参照し必要な手続きを行うこと。

リソースへのアクセス制御

リソースへのアクセス制御は主に操作権限や通信の制御を意味する。操作権限のシステム的な制御は従来、OS やアプリケーションで実装されてきたが、クラウド環境では、これに加えてCSPが提供するリソース（サービス含む）の操作に関する制御の考慮が必要になる。また、通信のアクセス制御は、CSP特有の機能を利用したゾーニングやファイアウォールなどの利用が必要である。

アクセス制御においては、予期せぬトラブルやインシデントを避けるため、アクセス主体への必要最小限の権限付与が重要である。これは最小権限の原則と呼ばれる。CSPではAPIによる操作が可能になり、リソースへのきめ細かなアクセス制御設計が可能である。細かい粒度で最小権限を実現できる一方で、アクセス権の設計や運用上の負荷が著しく高まる場合がある。このため、CSP環境の利用形態に合わせて最小権限の粒度を変化させることを推奨する。

例えば、開発環境と本番相当環境で同じようなアプローチを採用する必要はない。開発環境は保護すべきデータが存在しないように構成する。また、開発作業が遅延なくスムーズに、ときには試行錯誤しながら進められるように構成されている必要がある。このようなケースでは細かい粒度のアクセス制御は破綻する。

こうした場合は、多要素認証の設定やログの取得などのセキュリティ機構を変更されないような必要最低限の制限を実施する。

一方で、本番相当環境については考慮する余地がある。本番相当環境として運用されている場合、その運用業務は大きく「定型的な内容」と「非定型的な内容」に分類される。

• 定型的な内容：サービスの監視など、システムの安定的な維持を目的とした作業内容が明確な運用業務
• 非定型的な内容：トラブルシューティングなど、作業内容が規定できない運用業務

「定型的な内容」については作業内容が明確であるため、細かい粒度のアクセス制御設計が可能と考えられる。「非定型的な内容」については作業内容が事前に予測不可能なため、時限的な強い権限の付与が考えられる。厳密なアクション単位の設計を行わない反面、必要に応じて発見的統制の観点から作業が正しく行われているのかを点検する。

このように環境やユースケースを想定しながらメリハリをつけて最小権限の粒度を使い分けることを推奨する。

図003-E　環境別の最小権限アプローチと発見的統制による補完例

通信の限定と暗号化

HTTP、FTPなどの暗号化されていない通信では盗聴、改ざんのリスクがあるため、使用しない。VPC外部との通信は閉域網であってもHTTPS、SFTPなどの暗号化された通信に限定する。VPC内部の通信も暗号化を推奨する。
ストレージに保存されるデータのうち、機密性の高いものに関しては、暗号化を行う。また、認証情報、APIキーなどのシークレットはコード内や環境変数に保存せず、CSPが提供するシークレット管理サービスに保存する。
HTTPSを使用する際にサーバ証明書が必要になるが、CSPが提供するサーバ証明書の自動更新サービスが正しく動作せず、証明書の有効期限切れでアクセス不能となるケースがある。自動更新サービスを使用する場合は正しく動作することを確認した上で運用すること。

保管データの暗号化

ガバメントクラウドにおけるデータの暗号化では原則として利用システムの管理者が主体的に管理できる暗号鍵（例：カスタマーマネージドキー）の利用を強く推奨する。これにより以下を実現できるようになる。

• 暗号鍵へのアクセスログの取得
• 暗号鍵への細かなアクセス制御
• 明示的な暗号鍵の作成‧削除とそのログの取得

暗号化対象としては、データベースやストレージのサービス、OSにマウントするストレージ等、業務データを保管しうる領域すべてとなる。利用終了時のデータ消去については、クラウド事業者自身がNIST SP 800-88 などの国際的なデータ消去基準に準拠した方式で実施していることを監査報告している場合もあるものの、たとえば、NISC「政府機関等のサイバーセキュリティ対策のための統 基準群」で言一及されているクラウド環境における「暗号化消去」による利用終了データの削除を行いたい場合は、この暗号鍵管理方式が必要となる。

なお、暗号鍵の作成や鍵へのアクセス権付与などの管理は、原則として利用組織単位で行う。ただし、複数の利用組織によるクラウド環境の共同利用においては、共同利用単位による暗号鍵の管理とする。共同利用時においても、アクセス制御等の懸念がある場合は、利用組織毎に暗号鍵を管理することを妨げるものではない。

WAF/ファイアウォール

• WAF
  Webアプリケーションを運用するにあたり、サイバー攻撃への対策が必要となる。攻撃の種類は多様化しており、アプリケーションの実装、ミドルウェアの設定ではセキュリティ対策に限界がある。このため、Webアプリケーションの前面部にWAFを配置することが重要である。
• ファイアウォール
  オンプレミスの場合、ファイアウォールは外部と内部のネットワークの境界に配置する。クラウドではゼロトラストの考え方に基づき、内部からのアクセスであっても信用せず、必要なIPとポートのみ許可する。

　

DDoS対策

DDoS攻撃への対策は、以下のようなものがある。

• 攻撃対象領域の削減
  外部に公開する箇所を最小限にし、1か所での保護で済むようにシステムを構築する。また、公開する箇所をコンテンツ配信ネットワーク(CDN)やロードバランサーにすることで、アプリケーションへのトラフィックを制限することができる。
• スケーラビリティの確保
  大規模なボリュームDDoS攻撃に耐えるため、帯域とサーバ容量に拡張性を持たせる。
  マネージドサービスのCDNはトラフィック量に応じてスケールするため、帯域の確保に役立つ。
  サーバー容量は負荷に応じて自動的に拡大と縮小する構成にすることで、拡張性を確保する。
• CSPが提供するDDoS対策用サービスを利用する
  CSPがDDoS対策用のサービスを提供している場合、それを利用することでDDoS攻撃を軽減できる。

　

マルウェア対策

マルウェア対策として、マルウェア対策製品の導入を実施し、それを以て対策完了とする場合があるが、それだけでは不十分である。日常的に脆弱性対策を実施してマルウェア感染リスクを軽減すること、不審な動きがあった場合は速やかに検知し、可及的速やかに対処することが重要である。マルウェア対策製品の導入は、こういった対策の補完として位置付ける必要がある。

脆弱性対策を実施した上でのマルウェア対策としては、ウイルスやマルウェアが混入しうるファイル（TextやCSVではないバイナリーファイル等）が送られてくる経路が存在する場合は、そのファイルが実行されないように取り扱うようなアプリケーション構成にする。もしそうしたファイルを実行できるOS上に保存する必要がある場合は、そのOSについてサードパーティのウイルス対策ソフトの利用を検討する。例えば、ファイルアップロードを受け付けるアプリケーションでも、ファイルを直接マネージドストレージサービスに保管することで、ファイルが実行されるタイミングはなくなる。
また、CSPのサービスでマルウェア対策として利用できるものもあり、それらも活用する。

仮想サーバーを利用せず、マルウェアが活動して実害が発生する領域が存在しない場合は、マルウェア対策は不要。コンテナを利用している場合はread onlyにすることで対処する。また、本来マネージドであるストレージサービスをOSのファイルシステムにマウントするサードパーティー製品があるが、マルウェア対策が必要なポイントが増加するため、非推奨とする。

脆弱性対策

仮想サーバー、コンテナを利用しているシステムの場合、OSやミドルウェアの脆弱性の情報を収集し、適切なセキュリティパッチを適用する必要がある。
また、CSPが用意するセキュリティ評価サービスを使用し、脆弱性のチェックを行う。

仮想サーバーやコンテナを利用しないなど、脆弱性対策の対象が存在しない場合は、脆弱性対策は不要。

CI/CD

CI/CDパイプライン、リポジトリ、デプロイ先のコンテナなど、アプリケーションの開発とリリースにかかわるユーザーを制御し、セキュア化することでアプリケーションのセキュリティを確保する。ユーザー制御の具体的な方法は、多要素認証の使用、アクセス制御を参照。

また、リリース時の承認フローに、責任者の承認を必要とするプロセスを設けることで、レビューなしでリリースが行われることを防止できる。

コードに含まれる脆弱性対策として、リリース前に脆弱性スキャンを行うCSPサービスまたはサービス製品をパイプラインに組み込む。手動で脆弱性スキャンを行う場合、実施漏れが発生することがあるが、パイプラインに組み込んだ場合は、必ず実施が行われる。

ログの取得と分析

システム運用の上で、CSPサービス、アプリケーションなどのログの取得は重要である。適切なログの取得と管理を行うことで、システムの安全性と信頼性が確保できる。ログは以下のような観点で使用される。

• セキュリティ対策
  ユーザーのアクセス情報や操作履歴など、システムのセキュリティに関する情報が記録される。不正アクセスや情報漏洩などのインシデントが発生した場合に、ログから原因の分析が可能である。
• トラブルシューティング
  システムに障害が発生した場合に、ログを分析することで問題の原因を特定できる。
• パフォーマンスの改善
  ログからシステムのパフォーマンスに関する情報を抽出することで、ボトルネックや負荷が集中している箇所を特定できる。該当の箇所を改善することで、システムの改善や最適化が行える。
• セキュリティ要件の遵守
  PCI DSSの準拠など、ログの適切な保管が要件となる場合がある。

構成変更の記録と自動検知

システムの構成情報に変更があった場合、変更があったことの自動検知、それがポリシーに適合する内容であるかを自動チェックした結果を管理者に通知するシステムを構築する。また、構成情報の履歴を残し、過去の構成に戻せる状態にしておく。

ベンチマーク/ベストプラクティス自動チェック

システムがセキュリティのベストプラクティスに適合しているかを確認するためのツール、サービスを利用し、必要に応じて修正を行う。代表的なベンチマークにはCIS Benchmarksがあり、各CSP用のベンチマークが用意されている。CSPが独自のペストプラクティスに適合しているか確認するためのサービスを提供している場合は、併せて実施を行う。

AIによる不正自動検出

不正行為の方法は常に変化しており、一定のルールやパターンマッチングによる検出では検出率が低く、また、誤検知も多くなるため、対応として不十分である。AIを用いることで最新の不正行為にも自動かつ迅速に対応可能になる。

運用

定期的な改善活動

セキュリティ水準を保つためには、日々の運用の中で問題点の検出と対応を行い、改善していくことが重要となる。具体的な内容については技術マニュアル「発見的統制内容説明」の「発見時のアクション」を参照。

テンプレート/IaCファイルを使って構築することで実現されるセキュリティ

手動による構築を行う場合と比較し、テンプレート/IaCファイルを使った自動構築では事前チェックによる設定ミスの軽減、作業人員を減らすことによる本番相当環境のセキュリティリスクの軽減などの、セキュリティ上のメリットがある。本項では、これらのメリットについて記述する。

ベストプラクティスを含むサンプルIaCファイルの利用

ガバメントクラウドから提供するサンプルIaCファイルはベストプラクティスを組み込んで作成しており、これをベースとして利用すればセキュリティの欠陥が少ないシステムの構築が可能である。

事前チェックによる欠陥の早期発見

システム構築前にテンプレート内容をレビューすることにより、設定ミスや考慮漏れなどの欠陥を事前に発見でき、早期対処が可能になる。

自動構築によるミスの軽減

手動でシステム構築を行う場合、設定の元となるパラメータシートに誤りがなかったとしても、ヒューマンエラーによるミスが発生する可能性がある。自動構築の場合は、テンプレート内容通りに構築が行われるため、設定ミスが発生しない。

本番相当環境の人員削減によるセキュリティリスクの軽減

手動でシステム構築を行う場合、ダブルチェックなどのために作業担当者以外の人員が本番相当環境に入ることになり、その分のセキュリティカードやIDを発行する必要がある。これらの管理や紛失リスクを削減できるため、セキュリティリスクの軽減になる。

払い出し時に自動的に設定される予防的・発見的統制

クラウドでは誤った設定による意図しない情報の外部公開を避け、システムをセキュアに保つため、様々な設定を正しく行い、維持することが重要となる。
予防的統制とは不正な操作を事前に防止することであり、発見的統制とはリソースが不正な状況になっていないかを継続的に監視し修正する機能である。

ガバメントクラウドでは、上記の予防的統制および発見的統制の仕組みをCSPサービスおよびテンプレートによって実施する。

詳細については技術マニュアル「予防的統制内容説明」、「発見的統制内容説明」を参照。

改訂履歴