米国国防総省（DoD）は、クラウドと新しい標準を採用することで情報システムの高度化を進め、国家サイバーセキュリティ戦略の第1の柱や、大統領令（EO）14028「国家のサイバーセキュリティの改善」の第3条、国家安全保障・国防総省・インテリジェンスコミュニティのシステムのサイバーセキュリティ改善に関する国家安全保障覚書（NSM8）の第1条で求められている、サイバーセキュリティの近代化を推進することができます。
しかし、戦闘員のための、脅威情報に基づいた最新のインフラを構築するという同省の目標は、単独で達成できるものではありません。クラウドサービスを安全に運用する取り組みは、DoDのミッション責任者とクラウドサービスプロバイダー（CSP）との共同責任です。国防情報システム局（DISA）のクラウドコンピューティングセキュリティ要件ガイド（CC SRG）にガイドラインが記載されており、商用クラウドコンピューティングを導入するためのフレームワークを提供しています。
このフレームワークの基盤となるのがインパクトレベル（IL）です。各ILは、情報の機密性とリスクのレベルに対応し、国家安全保障システム委員会（CNSSI）No. 1253のセキュリティコントロールの要素と整合しています。また、これらのILは接続要件も規定しており、クラウドアクセスポイント（CAP）を含むものもあります。CAPは、クラウドサービスがDISAや各サービスのセキュリティスタックを経由して、NIPRNetに接続するための接続ポイントを提供します。さらにDISAは、クラウドサービス提供（CSO）の評価と認可のためのリスクマネジメントフレームワーク（RMF）プロセスを策定しており、これはDoD向けに特化したもので、連邦リスク・認可管理プログラム（FedRAMP）と並行して運用されています。
特定のCSOがどのレベルで運用されるべきかを理解するのは難しいことではありません。そのシステムが担うミッションと、処理するデータの性質を理解すればよいのです。以下に例をいくつか示します。
|
インパクトレベル |
機密性 |
ユースケースの例 |
|
IL2 |
パブリック |
軍の売店（Military Exchange）の販売サイト、public.cyber.milなどの一般公開Webサイト、または一般公開されている情報リポジトリ |
|
IL4 |
管理された非機密情報（CUI） |
Eメール、採用システムなどの業務システム、またはその他の機密性のある業務情報や個人データ |
|
IL5 |
国家安全保障システム（NSS） |
戦域内の資源を管理する兵站システム、戦闘関連の整備システム、またはその他の機密性の高い軍事・情報データ |
|
IL6 |
最高機密（SECRET）までの機密情報 |
指揮統制システム、またはその他の機密性の高い軍事作戦や極めて機微な政府活動 |
OktaのDoD対応への歩み
この1年間、OktaはDISAと緊密に連携し、パイロットプログラム承認に関する制限を受けない専用環境で、DoDおよびそのミッションパートナー向けにIDaaS（Identity-as-a-Service）の提供拡張を進めてきました。この取り組みはすでに完了しており、その成果として、Okta for US Militaryに対する新たな条件付き暫定認可（PA）が付与されました。また、この重要な節目に際して、OktaのIDaaSはDISAの認可責任者（AO）からIL5環境向けのアイデンティティとアクセス管理サービスとして認められました。
では、IL4のIDaaSをどのようにIL5システムへのアクセス管理に利用できるのでしょうか。この疑問に答えるには、コントロール（セキュリティ管理策）とデータの観点に立ち戻る必要があります。
まずはデータから見ていきましょう。IDaaSはクラウドベースのアイデンティティとアクセス管理（IAM）プラットフォームであり、他のシステムやアプリケーションへのアクセスを管理するための中央管理ポイントを提供します。ただし、従来の意味でデータを処理するわけではありません。では、ユーザーディレクトリにはどのようなデータを保存すべきでしょうか。通常、国家安全保障情報、機密性の高い個人識別情報（SPII）、保護対象保健情報（PHI）などをアカウント属性として保存する必要性はほとんどありません。ゼロトラストモデルの基本原則の一つは、「攻撃者はすでに環境内に侵入している可能性がある」と想定することです。保護対象の情報をアカウント属性として持たせてしまうと、攻撃者の作業をむしろ容易にしてしまいます。IDaaSを、システム全体（または複数システムの集合）を支える基盤機能として捉えれば、ディレクトリに保護対象データを保存すべきではないことは明らかです。たとえば、人員を一意に識別する必要がある場合は、社会保障番号（SSN）ではなく、電子データ交換人事識別子（EDIPI）を使用することが推奨されます。
次に考慮すべき要素は、コントロール継承モデルです。IDaaSは、システム全体のアーキテクチャの一部として機能することで、継承可能なセキュリティコントロールを提供します。Oktaのシステムセキュリティ計画（SSP）と継承可能なコントロールは、継承モデルを設計するすべての人にとって非常に貴重な参考資料となります。IDaaS自体はCUIデータを一切保存しないため、IL5で追加されるセキュリティコントロールの多くは、CUIデータを保存するシステム側に適用する必要があります。Oktaはハイブリッドなアプローチの一環として、これら追加要件への対応を支援できます。この考え方に基づき、Oktaが直接影響を与えるコントロールのみが継承可能として扱われます。たとえば、Oktaは自身に保存されるデータに対してFIPS 140-2準拠の暗号化を提供しますが、これは戦闘関連の整備システムに保存されるデータには適用されません。
最後の要素として、Oktaは追加投資を行い、.milドメイン上で環境をホストして、DoDが承認した組織のみに利用対象を限定しました。これは、DoDへの継続的なコミットメントの一環として重要なステップです。データ、コントロール、そして専用性というこれらのアーキテクチャ要素が、DISAがOkta for US Militaryに対してIL4での条件付きPAを付与し、IDaaSをIL5環境のサポートに利用することを認めた論理的な根拠です。このユニークな事例は、DoDのクラウド移行とゼロトラスト推進において、Oktaが今後も重要な役割を担うことを示しています。
この取り組みや、Oktaが統合しているIL5アプリケーションについて詳しくは、国家安全保障のための最新アイデンティティの展開のホワイトペーパーをダウンロードするか、federal@okta.comまでお問い合わせください。
