執筆者: Maril Vernon(Anecdotes、フィールドCISO)
私は長年、攻撃側のセキュリティに携わり、レッドチームおよびパープルチームの評価担当として、GRCチームや、時には監査人までもが「機能している」と確信していた統制を突破する仕事をしてきました。
ネタバレをすると、それはめったに、あるべき水準ほど難しくはありませんでした。各チームが不注意だったからではありません。彼らが評価される仕組み自体が、「ある一時点で統制が存在することを証明する」ことを評価するものであり、「監査から半年後のある平凡な火曜日にも、運用上その統制が保たれているか」を評価するものではなかったからです。
FedRAMP Rev5は、まさにそのモデルの上に構築されていました。組織は統制の実装方法を文書で説明し、その説明をNIST 800-53にマッピングし、慎重に選定したエビデンスで裏付けます。
そして監査人は、その実装が文書の内容と一致しているかどうかを判断するために、年に一度エビデンスをサンプル抽出して確認していました。しかし、監査に一度でも関わったことがある人ならわかるはずです。これがどれほどスコープや説明の作り方に融通を利かせる余地を残すか。そして、ペネトレーションテスターの経験がある人なら、まさにそこが最初に狙うべきポイントであることも知っているでしょう。
FedRAMP 20xは、そもそもの問いを根本から変えます。組織にセキュリティ態勢の「説明」を求めるのではなく、それを「継続的に証明する」ことを求めるのです。この変化は些細に聞こえるかもしれませんが、保証(アシュアランス)というものの意味そのものを根底から変えてしまいます。
最大の変化はフレームワークではなく、エビデンスにある
FedRAMP 20xは、説明文重視の統制を、測定可能な結果と機械可読なエビデンスに裏付けられた「主要セキュリティ指標(KSI:Key Security Indicators)」に置き換えます。
Lowベースラインには56個、Moderateベースラインには61個のKSIが存在し、クラウドネイティブアーキテクチャ、アイデンティティ・アクセス管理、モニタリング、インシデント対応、変更管理を含む12のセキュリティ領域に分類されています。
このフレームワークは、「プロセスを文書化したかどうか」を問う姿勢から離れ、「そのプロセスが実際に機能しているか」を示す方向へと移行しています。
単純な例で違いを見てみましょう。Rev5では、ある統制が多要素認証(MFA)ポリシーの説明を求めるかもしれません。これに対応するKSIでは、機械可読なエビデンスを用いて、現時点で本番環境のすべての特権アカウントにフィッシング耐性のあるMFAが適用されていることを証明するよう求められます。
片方は選定されたエビデンスに裏付けられた「主張」であり、もう片方は「客観的な事実」です。事実は、監査の場で議論の余地がはるかに少なくなります。
年次評価への最適化に何年も費やしてきた組織にとって、これは単なる文書更新にとどまりません。監査が近づいたときにエビデンスをかき集めるのではなく、信頼できるエビデンスを継続的に生み出せる仕組みを構築することが求められるのです。
現代の脅威が継続的だからこそ、継続的な保証が一時点の保証に勝る
FedRAMP 20xにおける最大の運用上の変化は、統制の内容そのものではなく、その「頻度」にあります。
Rev5では、一時点の評価を裏付けるためにエビデンスが収集されていました。20xでは、エビデンスは生きたシステムの一部となります。
機械ベースのKSIは短い周期で繰り返し再検証され、Moderateシステムでは数日おきに行われる場合もあります。一方、プロセスベースのKSIについても、少なくとも四半期ごとの検証が求められます。
もはや「決められた一定期間のうちのある時点で真実だったことを証明できる」だけでは不十分です。求められているのは、環境が絶えず変化し続ける中でも、それが真実であり続けることを証明し続けられることです。
これは、現代のインフラが実際にどう機能しているかを見れば納得がいきます。クラウド環境は絶えず変化しています。開発者は1日に何度もデプロイを行います。
アイデンティティは絶え間なく作成、変更、削除されています。攻撃者は何年も前から、監査後も環境が静的なままではいられないことを見抜いていました。
これまでコンプライアンスは、そうした変化が起きていないふりを続ける唯一の分野でした。
FedRAMP 20xは、その現実を認めた最初期の主要な保証フレームワークの一つです。システムが継続的に稼働しているなら、保証モデルもまた継続的に機能しなければなりません。
継続的な保証には継続的なエビデンスが必要
3日ごとにエビデンスパッケージを作成することなど到底できませんし、そもそもそうする必要もありません。20xの下では、エビデンスは実際に作業を行っているシステムから直接流れてくる必要があります。
つまり、該当する場合はOSCALに準拠した機械可読データに加え、コンテキストやタイムスタンプ、そして監査人が内容を理解できるだけの十分な情報を提供する、人間が読める形式の要約も必要になるということです。
フェーズ2の完全性ガイダンスでは、こうした要件が明確に示されています。自動化はKSIの少なくとも70%をカバーしなければならず、すべてのKSIに対応する必要があり、エビデンスは機械可読形式と人間可読形式の両方で存在しなければなりません。
これは単なる作業のための作業ではありません。現代の保証には、自動化と説明の両方が必要であるという認識の表れです。機械は大規模に検証を行えますが、そのデータが実際に何を示しているのかを理解するには、人間側にも十分なコンテキストが必要です。
Rev5から移行してきた組織にとって、この段階こそが、コンプライアンス対応というよりもエンジニアリングの仕事だと感じ始める瞬間であることが多いのです。
本当に必要な作業は「文書作成」ではなく「エンジニアリング」
それもそのはずで、Rev5と20xの最大のギャップは文書化ではなく、システム設計にあるからです。
最初のステップは、自分たちが今どの位置にいるかを把握することです。KSIギャップ分析を実施し、各要件を「完全対応」「部分対応」「未対応」でスコアリングしましょう。それぞれのKSIが自動化可能か、手動プロセスが必要か、あるいは両方が最終的に必要になるかを見極めます。
FedRAMPが推奨する優先順位に従い、まずFedRAMPによる認可から着手し、次にクラウドネイティブアーキテクチャとアイデンティティ・アクセス管理に進み、その後サービス構成、モニテリング、残りの領域へと進んでいきます。
そこから、エビデンスパイプラインを構築します。自動化可能なKSIの大半は、すでに組織がクラウドプラットフォーム、アイデンティティプロバイダー、SIEM、脆弱性スキャナー、構成管理ツールを通じて日々生成しているデータの上に成り立っています。課題は新たなデータを作り出すことではありません。
課題は、それを一貫して収集し、正規化し、KSIにマッピングし、構造化されたエビデンスを生成し、しかもそれらすべてを求められる頻度で、規模を保ちながら実行し続けることにあります。
皮肉なことに、最も骨が折れる作業は往々にして技術的なテレメトリではありません。ポリシー承認、ガバナンスのワークフロー、研修記録など、そもそも継続的に運用されることを想定して設計されていなかった手作業のプロセスこそが厄介なのです。これらは通常、最も時間のかかる項目であり、だからこそ最初に取り組む価値があります。
監査人の役割も変わります。Rev5では、3PAO(第三者評価機関)は文書や説明の評価に多くの時間を費やしていました。20xでは、エビデンスパイプラインが実態を正確に反映しているかどうかを検証することになります。
監査は、ポリシーを読むことから、エビデンスを生成するシステムの整合性を信頼することへと重心が移っていきます。
組織が文書化していた内容と、実際に環境内で起きていたこととの間のギャップを何年も見つけ出す仕事をしてきた者として言えるのは、これによって脅威アクターが身を潜める場所の多くが失われるということです。
目指すべきはただの自動化ではなく、持続可能性
だからといって、すべての組織がプラットフォームを購入しなければならないわけではありません。こうしたパイプラインは自前で構築することも十分可能ですし、実際に多くの組織がそうするでしょう。ただし、ここまで挙げてきたこと(エビデンスの収集、データの正規化、KSIへのマッピング、機械可読な出力の生成、人間可読な要約の作成、そしてそれらの連携の維持)を継続的に行うのは、あっという間に絶え間ないエンジニアリング作業になっていきます。
そこで自動化が力を発揮します。人間にできない仕事だからではなく、高度なスキルを持つエンジニアの時間を、エビデンスパッケージを何度も作り直す作業に費やすよりも、もっと有意義に使う方法があるからです。
持続的な検証は、恒久的な手作業のプロジェクトではなく、運用能力の一つとして組み込まれるべきものです。
Anecdotesでは、自社のプラットフォームを用いてFedRAMP 20x Moderate(クラスC)の認可を取得した初のエージェント型GRCプラットフォームとなった際に、まさにこれを身をもって体験しました。
最初の評価でいきなりModerateに到達したわけではありません。当初はLowにとどまり、その結果を踏まえて環境を改善し、再度検証を行い、最終的にModerateを達成しました。
私にとって、これこそがこのフレームワークが意図通りに機能している何よりの証拠です。FedRAMP 20xが評価するのは、最もきれいな説明を語る組織ではなく、評価をフィードバックループとして捉え、継続的に改善を重ねる組織なのです。
必要に迫られる前に始める
Rev5対応の組織が犯しがちな最大の過ちは、20xを単なる書類の移行作業として扱ってしまうことです。
信頼できるエビデンスを継続的に生み出す仕組みを構築せず、SSPをただマッピングし直すだけで済ませてしまえば、最終的には期限に追われながら、すべてを手作業で一から作り直す羽目になります。そしてそれこそ、20xがなくそうとしている事態そのものなのです。
最も複雑な統制から着手してはいけません。まずは地味なものから始めましょう。すでに大半のデータが揃っているKSIを一つ選び、エンドツーエンドで計測できるようにし、継続的な検証を実行してみてください。何が破綻するかを確認し、修正し、それを繰り返します。規模を拡大する前に、まずその「筋力」を鍛えることが大切です。
なぜなら、FedRAMP 20xが問うているのは、一度の監査を乗り切れるかどうかではないからです。問われているのは、監査後に訪れるあらゆる平凡な火曜日を、あなたの保証プログラムが乗り越え続けられるかどうかです。この移行に成功する組織とは、最も優れた文書を持つ組織ではありません。期限に追われる前から、継続的な保証の構築に着手していた組織なのです。
さらに詳しく知りたい方へ。AnecdotesのCISOであるJake Bernardesが、Rev5から機械可読な継続的保証への移行について、セキュリティ・リスク・コンプライアンス部門のリーダーでエージェント対応を進める方々向けのバーチャルイベント「GRC Data and AI Summit 2026」(2026年8月12日開催)で詳しく解説します。
Rev5の期限が迫っている方は、まさにこのセッションに参加すべきです。無料登録はこちら。
執筆者について
Maril Vernonは、AnecdotesのフィールドCISOであり、レッドチーム・パープルチームの元運用担当者です。GRCエンジニアリング、継続的統制モニタリング、攻撃的セキュリティ、そして現代の保証プログラムの進化について執筆・講演を行っています。彼女の活動は、コンプライアンスを単なる文書作成の作業から脱却させ、信頼できるリアルタイムデータに基づいたセキュリティ上の意思決定へと組織を導くことに主眼を置いています。Anecdotesは、自社のプラットフォームを活用してFedRAMP 20xの認可を取得した初のエージェント型GRCプラットフォームです。
