米国連邦政府におけるクラウド戦略 - クラウドセキュリティをどう担保するか｜ミック (original) (raw)

さて、米国連邦政府のクラウド戦略についてのレポートその2である。その1はこちらを参照。その1を読んでいなくても支障はないが、歴史的な話をしているので先に読んでいただくと理解が捗ると思う。

前回は、どちらかというと連邦政府の取り組みがうまくいかなかった、というトーンで話をしたが、公平を期して言うならば、成功している部分もあるし、うまくいかなくても諦めず粘り強く進行している取り組みもある。こういうとき米国人というのは強くて、失敗を教訓にどんどん再トライを繰りかえし、大きなブレイクスルーに繋げてしまう。

本稿では、そのようなダイナミズムを持った取り組みとして連邦政府のクラウドセキュリティ戦略を取り上げたいと思う。今後日本政府がクラウドシフトを進めていくうえでの参考にもなれば幸いである。

連邦政府のクラウドセキュリティ政策は、大きく三つの柱から成り立っている。一つ目が「FedRAMP」と呼ばれるクラウドベンダに対するセキュリティの認証基準、二つ目がデータに関するセキュリティ標準、そして三つ目がセキュリティを高めるための開発技法としてのDevSecOpsである。それぞれ順に見ていこうと思う。

FedRAMPとは何か - 銀の弾丸か参入障壁か

FedRAMPとは、Federal Risk and Authorization Management Programの略称であり、クラウドサービスのセキュリティ評価、承認、および継続的な監視に対する標準化されたプロセスである。日本のISMAPがおそらくこのFedRAMPを参考に作られている。

FedRAMPの審査に合格すると操業免許（ATO：Authority to Operate）をもらえる。すべての連邦政府機関は、FedRamp認証済みサービスしか利用できないとされている。ただし現在でも3割程度FedRamp認証外サービスが調達されている（プライベートクラウドには例外が認められているため）。FedRAMPは、時々、特別な新しいセキュリティ基準を作ったものと誤解されていることがあるが、既存のFISMAやFIPSといった法律や基準をもとに統一的な基準に作り替えたものである。

FedRAMPは既存の法令の統合版

米国には業界別に医療分野のHIPPAや金融分野のPCIなどセキュリティ標準が存在する。その連邦政府版がFedRAMPだと思ってもらえればよい。FedRAMPには複数のレベルがあり、レベルによって審査項目の数が変わる（ Low:158、Moderate:325、High:412 ）。これは他の業界標準と比べても非常に多い。対面デモや口頭試問、ペネトレーションテストもあり、審査に時間と金がかかるのが特徴だ。

FedRAMPのポイント

FedRAMPの重要なポイントを挙げると以下のようなものがある：

この最後の点については、FedRAMPは実質的に中小企業を排除する参入障壁として機能しているのではないか、という批判にも繋がっている。下記の記事を参照。

連邦政府のサイトでは、FedRAMP認証済みサービスの一覧が公開されている。認証済みサービスの数は334(2024年4月時点)。 AWSやAzureといった定番のクラウドもいれば、Snowflakeのような比較的新興の企業も顔を見せている。筆者が駐在をしていた2020年頃には200くらいだったので、順調に数を増やしている。

FedRAMPの主な審査項目

さて、それではFedRAMPではどのような審査が行われているのだろうか。全部を書き出すのは非現実的なので主な項目を以下に挙げる。全体的な印象としては、「当たり前のことが漏らさず書かれている」という印象である。

セキュリティの心得がある人が見れば、それほど特別なことではないが、それなりにコストと体制の必要なことを言っているな、という印象を受けると思う。米国人は書かれていないことはすぐに手を抜くため、当たり前のことを漏らさず書くのが重要なのだ。米国の教科書やマニュアルが分厚くて驚いた経験をしたことのある人もいるだろう。しかし同時に、FedRAMPが中小企業に対する参入障壁になっているという批判にも頷けるものがある。

さて、以上で見たように、連邦政府に自社のクラウドサービスを使ってもらうためには、まずはこのFedRAMP認証を勝ち取らなければ始まらない。その意味で連邦政府のクラウドシフトの門番の役割を果たしている。逆に内向きに対しては、ホワイトハウスが各省庁に向かって「これだけのことをやってますから、このクラウドサービスは安心して使ってもらって大丈夫です」と太鼓判を押す役割を持っている。連邦政府の機関が最もクラウドに抵抗を示すのは、セキュリティへの不安だというのは前回見た通りである。安心安全であることをアピールしてしすぎることはないのである。

データは守るものか、それとも共有するものか

FedRampはクラウドサービス自身とサポート体制の観点からの基準だが、扱われるデータの機密性についてはフォーカスしていない。機密性レベル（IL：Impact Level）に応じたセキュリティ対策は、実質的に以下の二つの施策によって実現されている。

DoD CC SRG (Cloud Computing Security Requirements Guide)

国防総省(DoD)が定めるクラウドサービスのセキュリティ・ガイドライン。データの機密性に応じたインパクトレベル1～6でデータを分類し、求められる対策を定めている(レベル1と3は使われていないので実質4種類) 。FedRAMP ModerateはCC SRG IL2を充足するとされているため、両者は部分的には互換性があるとも言える。ILは、具体的には以下のような区分になっている。

ペンタゴンの情報機密レベル

Classified：国家安全保障にかかわる複数のレベル（Top Secret、Secret、Confidentialなど）から構成される。基本的にどのような情報が相当するかの具体例は公開されていない。
NSS(National Security Systems)：国家安全保障、機密情報、米軍の作戦、軍事兵器の管理、および関連する情報活動に関する情報を管理するシステムの情報。
PII (Personally Identifiable Information)：運転免許証番号、パスポート番号、クレジットカード番号、SSN、氏名、電子メールアドレス、IPアドレス、指紋、etc.
CUI(Controlled Unclassified Information)：病歴、入院日、退院日、死亡日、電話番号、FAX番号、住所、口座番号。PII、PHIに加えて法的手続きの情報。

この中で目を引く存在として、CUIというものがある。政府クラウドはこのCUIを扱うために作られたと言っても過言ではないのだが、これが何なのかわかりにくいので少し解説をしておく。

CUIは「**機密(Classified)ではないが、取り扱い注意(Controlled)**」という意味の分かりにくい情報種別で、アルカイダに関する情報が政府機関で共有されていなかったことで9.11テロを未然に防ぐことができなかったという反省にもとづいて、従来100種類以上あった情報種別を統一的に置き換えるカテゴリとして作られた。法的根拠としては2010年の大統領令13556である。

AWSによるCUIのカテゴリ分け

このCUIは一見して分かる通り非常に雑多で、いろいろな情報を大鍋にぶち込んでしまったものだ。このCUIにすべてを入れ込むことで、機関同士の情報共有を促進する目的がある。しばしば、「Need-to-KnowからNeed-to-Shareへの転換」と言われる、画期的な施策である。

Government Cloud(GovCloud)

ILに応じてCSPが設置している政府専用リージョン。現在はAWSとAzure、Oracleなどが対応している。専用リージョンを持ち米国市民権を持つ従業員のみがオペレーションに携われる。その分割高で高コスト。そのネットワーク構成は下図のようになっている。

政府クラウドのNW構成図

NIPRNET（ニッパーネット）というネットワークが気になると思うが、これは国防総省が管理するDMZセグメントで、1980年代から運用されている。インターネットからアクセス可能で、GovCloudへの接続を中継する。境界保護とアクセスログ監視の機能を持ついわゆる踏み台である。NIPRNETについてはこちらの記事も参考にしてほしい。

しかしこの政府クラウドは、CSPからはすこぶる評判が悪い。わざわざこんなものを用意する必要などないというのだ。特にGoogleがあけすけに批判しているので、その言を聞いてみよう。

私たちは、もっと良い方法があると信じています。それは、デジタル要塞のような錯覚を与える特殊な政府クラウドは本当は必要ないということを認めることから始まります。

Jeanette Manfra, Director for Government Security and Compliance, Google Cloud

Googleの言い分を簡単にまとめると以下のとおりである：

AWS・Microsoft「さすがGoogleッ! オレたちに言えないことを平然と言ってのける！（棒）」

まったく、言いたい放題である。仮にもお仕事をいただくお客様に向かってこんな痛烈な批判をかましていいものだろうか。でも言っちゃうのが米国人クオリティである。それにまあ、Googleの言い分にも一理あるのも事実である。政府クラウドは専用リージョンを分けてオペレーション要員のセキュリティクリアランスも必要なのでコストも高くなっている。

以上で見たように、米国政府のデータの取り扱いはかなり洗練されており、コストと時間をかけて構築した仕組みが機能している（政府クラウドのように批判を浴びているものもあるが）。特にCUIのようなデータ共有を促進しつつ守るべき情報は守るという施策は、日本も大いに学ぶべきところがあると思う（筆者も所属組織の情報種別ラベルの煩雑さには辟易している一人である）。

DevSecOps

連邦政府は歴史的にHW/SWエンジニアやプロジェクトマネージャを多く登用、雇用してきた歴史があり、開発・運用を自組織で行う内製の文化が根強いが、これは高コスト体質および非効率なプロジェクトの原因でもあった（その1参照）。こうした問題を解決するため、近年アジャイルの開発手法として注目されているDevSecOpsの採用が進められている。

イニシアティブをとっている組織は以下の二つである。

18Fが情報連携、育成、コミュティ運営やイベント・ワークショップ開催などの横串、USDSが個別プロジェクトベースの支援という縦串の組織という位置づけになっている。

米国空軍のDevSecOps - Cloud One

DevSecOpsの取り組み事例として、米国空軍のDevSecOpsプラットフォーム - Cloud One/Platform Oneを見てみたい。DevSecOpsについては、ペンタゴン配下の軍関連の組織が先進的である。これには次のような理由がある。

  1. 多くのCSP/MSPはFedRamp Moderateを取得しているが、これはIL2相当なので、IL4-5を扱えるサービスが少なく、DoDにとってFedRampがあまり機能していない。
  2. 開発運用を自組織で行うことで、外部業者に頼らなくてよくなり人的バックドアを減らせる。

USAFのDevSecOpsプラットフォーム

このCloud Oneプラットフォームには以下のような特徴がある。

やはり日本と大きく違うなあと思うのは、連邦政府はエンジニアやプログラマを直接雇用しているので、自分たちでプラットフォームの構築や内製ができる点である。これが組織としての機動性に繋がっている。日本政府もこの問題には気づいており何とかしようとしているのだが、日本の法制度ではなかなか難しいところだろう。

Cloud OneのDevSecOpsサイクル

スノーデンの呪い

また、このペンタゴンのDevSecOpsの取り組みを見ていて思うのが、スノーデンのPRISM暴露事件が一つのトラウマになっているのだな、というのを強く感じる。スノーデンがPRISMの情報を持ち出したとき、彼は連邦政府の職員ではなく、契約しているコンサルティング企業の社員だった。しかし非常に広汎な情報のアクセス権を与えられており、自由に機密情報にアクセスすることができた。

エドワード・スノーデン

これの反省から、ペンタゴンは最終的には「政府職員（それもなるべく少人数）しかシステムを触れないようにする」ことを究極の目標に掲げるようになった。米軍の資料を見ていても、本番環境から人間のオペレーションを極力排除するという命題が見て取れる。日本では自動化は省力化のために行われることが一般的だが、米国ではセキュリティの観点から自動化を進めるモチベーションがあるのだ。

米軍のIaCに関する資料。「本番環境からの人間の排除」という文言が見て取れる

こうしたことから、米軍ではただのDevOpsではなくDevSecOpsが非常に意識されているというわけである。そして、それを可能にする豊富なエンジニアリソースを抱えていることがある。日本でそのまま実現するにはリソースが足りないかもしれないが、理念としては目指す価値があるものではないだろうか。

なお、米国空軍はDevSecOpsの取り組みについてウェビナーを公開している。公共分野でサイバーセキュリティを考える人にとっては非常に啓発的で参考になるので、一度見てみることをお勧めする。

総括

以上、三つの観点から連邦政府のクラウドセキュリティ対策を見てきた。前回はちょっと連邦政府を腐すような内容になってしまったが、今回はその先進的かつ挑戦的な取り組みを前向きに取り上げてみた。政府だけでなく一般企業においても参考になる取り組みが多いと思うので、皆さんの仕事に対する一助になれば幸いである。

その3へ続く。