本ブログは、CMMC 2.0におけるアイデンティティの役割について解説する3部構成シリーズの第1回です。
要点：あらゆるアクセス・ポリシーの根底にある重要な問い：「本当に本人であることを確認できますか？」
本記事では、識別と認証（IA）の管理策ファミリーについて詳しく解説します。より安全なアクセス制御を実現するために、なぜ強力な本人確認が必須の前提条件となるのかを解説し、CMMC 2.0のあらゆる成熟度レベルでOktaがこうした要件を満たすのにどのように役立つかをご紹介します。
概要：認証はアクセス制御の基盤
識別と認証（IA）のコントロールファミリーは、組織のデジタルゲートキーパーとしての役割を果たします。すべてのユーザー、デバイス、プロセスが正規のものであり、検証済みであることを確認したうえで、リソースへのアクセスを試行できるようにすることが目的です。リクエスト元のアイデンティティの確実性が疑わしい場合、いかに慎重にアクセス制御（AC）ポリシーを作成しても意味がありません。
このため、CMMC 2.0のスコアリング手法ではIAコントロールが非常に重視されています。監査人は、セキュリティ対策を信頼する前に、本人確認の確実性と証明が必要です。
Oktaを導入することで、組織はこうした価値の高い要件の大部分に即座に対応できます。IAファミリーだけでも、Oktaは5点に相当する3つのコントロールへの対応を支援します。これらは監査に合格するために不可欠な「重要項目」です。
CMMCの各レベルにおける主要なIA統制について見ていきましょう。
CMMCレベル1：基礎レイヤー
レベル1は「基本的なサイバーセキュリティ対策」に重点を置いており、連邦契約情報（FCI）を取り扱う委託業者に義務付けられています。これにより、必要な基本事項が確実に整います。
主要なレベル1の統制：IA.L1-3.5.1
CMMC要件 | NIST SP 800-53の相関コントロール |
|---|---|
IA.L1-3.5.1：情報システムのユーザー、プロセス、またはデバイスを識別し、認証します。 | IA-2：識別と認証（組織のユーザー）：情報システムは、組織のユーザー（または組織のユーザーの代理として機能するプロセス）を一意に識別し、認証します。 |
このコントロールでは、すべてのユーザーに一意のアイデンティティを発行し、共有アカウントを排除する必要があります。
Oktaによるコントロールの対応：
Okta Universal Directoryとシングルサインオン（SSO）は、このCMMC要件に対応するための最適なツールです。Oktaはすべてのユーザーアイデンティティの信頼できる唯一の情報源として機能し、各ユーザーが所有するアカウントを1つだけに限定します。アプリケーションをOkta SSOと連携させることで、すべてのログインに単一の固有のIDが使用されるようになり、共有アカウントは過去のものとなります。
- 実際のシナリオ：小規模なDIBサプライヤーが主契約者のポータルにログインして、納品スケジュールなどのFCIにアクセスします。共有のshipping@supplier.comアカウントを使用する代わりに、Oktaを使用して各従業員に一意のユーザーアカウントを付与します。従業員がポータルにアクセスすると、個人の認証情報を使用してOktaで認証します。これにより、すべてのアクションが従業員本人に直接関連付けられ、レベル1で求められる基本的な追跡可能性の要件を満たします。
IA.L1-3.5.1 設計に関する推奨事項：
このコントロールを実装するには、Oktaを人事システムなどの信頼できる情報源に接続するか、Okta Universal Directoryで直接ユーザープロファイルを作成して、Oktaを中央アイデンティティプロバイダーとして構成します。各アプリケーションに、SAMLまたはOIDCを使用してSSO統合を設定します。重要な点として、アプリケーションがOkta経由でのみログインを許可するように設定し、ユーザーがユーザー名とパスワードで個別のローカルアカウントを作成できないようにしてください。すべてのアクセスに、単一の管理されたアイデンティティの使用を強制します。
IA.L1-3.5.1 コンプライアンスの証拠：
監査人にコンプライアンスを証明するには、Okta Universal Directoryを提示して、各従業員に一意のユーザープロファイルがあることを示します。次に、主要なアプリケーション（Microsoft 365など）の構成ページに移動してSSO設定を表示し、Oktaとフェデレーションされていることを示します。最後に、Oktaのシステムログを表示し、特定のユーザーの最近のログインを絞り込んで詳細なイベントログを示すことで、すべてのアクションが一意のactor.idにまで追跡可能であることを証明します。
CMMCレベル2：CUIのゲートキーパー
レベル2は、より機密性の高い管理対象非機密情報（CUI）を取り扱う委託業者を対象としています。このレベルはNIST SP 800-171に準拠しており、はるかに堅牢なセキュリティが求められます。
主要なレベル2の管理策：IA.L2-3.5.3
CMMC要件 | NIST SP 800-53の相関コントロール |
|---|---|
IA.L2-3.5.3:ローカルアクセスとネットワークアクセスには多要素認証を使用してください。 | IA-2(1)：特権アカウントおよび非特権アカウントへのネットワークアクセス：情報システムは、特権アカウントおよび非特権アカウントへのネットワークアクセスに対して多要素認証を実装します。 |
この5つの重要項目からなる統制では、パスワードだけでは不十分であると定められています。パスワードの盗難から保護するために、2番目の認証要素（MFA）を適用する必要があります。
Oktaによるコントロールの対応：
Okta Adaptive MFAは、このCMMC要件に最適なツールです。一元管理されたアイデンティティプロバイダーとして、OktaはCUIを扱うあらゆるアプリケーションへのすべてのアクセス試行に対して、強力なMFAを適用できます。ポリシーは、すべてのユーザーにMFAを要求するように設定でき、ユーザーが信頼できないネットワークから接続している場合により強力な要素を要求するなど、リスクに基づいて適応させることができます。
- 実際のシナリオ：在宅勤務の航空宇宙エンジニアが、CUIを含むクラウドベースのCADアプリケーションにアクセスする必要があります。ログインするには、まずパスワードを入力します。その後、Oktaはユーザーに対し、登録済みのスマートフォンでプッシュ通知を承認するよう求めます。この第2要素を承認して初めて、機密性の高い設計ファイルへのアクセスが許可されます。パスワードをフィッシングで窃取した攻撃者も、MFAのチャレンジで完全に阻止されます。
IA.L2-3.5.3 設計に関する推奨事項：
Okta管理コンソールで、すべてのユーザーに少なくとも1つのMFA要素への登録を要求する「認証器登録」ポリシーを作成します。次に、「サインオンポリシー」を作成し、CUIを処理するすべてのアプリケーションに適用します。このポリシー内のルールを、すべてのログインで「多要素認証を要求する」ように構成します。ベストプラクティスは、ユーザーが信頼できないネットワーク上にいる場合は常に多要素認証（MFA）を要求するというルールを設定することです。さらにセキュリティ体制を強化するには、こうした重要なアプリへのすべてのアクセスにフィッシング耐性のある要素を要求してください。
IA.L2-3.5.3 準拠の証拠：
審査担当者に対しては、まず作成したサインオンポリシーを表示し、CUIを扱うアプリケーションへのすべてのログインでMFAを明示的に適用するルールを示します。その後、ライブデモを実施します。テストユーザーとしてそのアプリケーションにログインを試み、登録済みのデバイスにMFAプロンプトがライブで表示されることを評価者に示します。最後に、Oktaのシステムログで、そのユーザーに対応する「多要素認証」の成功イベントを提示します。
CMMCレベル3：エキスパートによる防御
レベル3は、DoWの最優先プログラムに参加している組織を対象としています。すべてのL2コントロールに加えて、NIST SP 800-172で定められた高度なコントロールを実装し、APT（Advanced Persistent Threat：持続的標的型攻撃）から保護する必要があります。
主要なレベル3の管理策：IA.L3-3.5.4e
CMMC要件 | NIST SP 800-53の相関コントロール |
|---|---|
IA.L3-3.5.4e:すべての特権アクセスと非特権アクセスに、フィッシング耐性のある多要素認証を導入してください。 | IA-2(8)：フィッシング耐性/リプレイ耐性：情報システムは、フィッシング耐性およびリプレイ耐性のある認証メカニズムを使用します。 |
この高度な制御では、フィッシング耐性のあるMFAの使用を義務付けることで、脆弱なMFAを回避する高度な攻撃を阻止します。
Oktaによるコントロールの対応：
Oktaは、業界で最も強力なフィッシング耐性のある認証器の一つであり、これらはCMMCのエキスパートレベルの要件を満たすツールです。これには、YubiKeyなどのFIDO2/WebAuthn準拠のハードウェアセキュリティキーや、Windows Hello、AppleのFace ID/Touch IDといったプラットフォームの生体認証を活用するOkta FastPassのようなパスワードレスソリューションが含まれます。Oktaのポリシーは、価値の高いCUI環境にアクセスするすべてのユーザーに対して、こうしたフィッシング耐性のある要素のみを必須とするように設定できます。
- 実際のシナリオ：一流の防衛関連企業のサイバーセキュリティアナリストが、機密性の高いCUIを含むシステムを管理しています。管理コンソールにアクセスするには、Oktaで認証する必要があります。パスワードを入力すると、ワークステーションに挿入されたYubiKeyにタッチするよう求められます。キーは、ユーザーとOktaサービスに固有の暗号化チャレンジレスポンスを実行します。これにより、最高レベルの保証でユーザーのアイデンティティが証明され、高度な攻撃者であっても認証情報を傍受することは不可能になります。
IA.L3-3.5.4e設計上の推奨事項：
Oktaの「認証器の登録」ポリシーで、FIDO2/WebAuthn認証器が有効になっていることを確認してください。次に、CUIアプリケーションのサインオンポリシーを作成または編集します。一般的なMFA要件の代わりに、「フィッシング耐性」を必須プロパティとして持つ認証器を明示的に要求するルールを作成します。このルールでは、YubiKeyやOkta FastPassといった、デバイスに搭載された生体認証を活用する要素の使用が必須となります。SMSやセキュリティの質問といった強度の低い要素で、機密性の高いアプリケーションにアクセスすることは許可されません。
IA.L3-3.5.4eコンプライアンスの証拠：
これを評価者に証明するには、フィッシング耐性のある認証器を必須とするように設定したサインオンポリシーのルールを提示します。次に、実際のログインのデモンストレーションを行います。まず、フィッシング耐性のない要素（プッシュ通知など）を使用してログインを試み、アクセスが拒否されることを示します。次に、YubiKeyまたはWindows Helloを使用したOkta FastPassで再度ログインし、アクセスが許可されることを確認します。これにより、確実な適用の証拠が提供されます。
堅実な基盤の上でCMMCの取り組みを続けましょう
強力なアクセス制御と、回復力のある識別および認証を組み合わせることで、CUIに対する堅牢な防御と、CMMC監査に向けた強固な基盤を構築できます。最新のアイデンティティプラットフォームで戦略を一元化することで、適切な担当者のみが適切なリソースにアクセスできるようになります。
本シリーズの次回の記事では、監査と説明責任（AU）のドメインを取り上げ、セキュリティコントロールが意図したとおりに機能していることを証明する方法について解説します。ご期待ください。
Oktaがお客様の組織のCMMC要件への対応をどのように支援できるかについて、詳細をご覧になるには、https://www.okta.com/resources/datasheet-okta-cmmc-discovery-guide/からOktaの「CMMCディスカバリーガイド」をダウンロードしてください。または、okta.com/contact-sales/までお問い合わせください。
本記事は特定の法概念について解説していますが、法的な助言を構成するものではなく、またそのように解釈されるべきではありません。本資料は情報提供のみを目的としています。貴社のコンプライアンス要件に関する法的なアドバイスについては、貴社の法務部門にご相談ください。Oktaは、本記事の内容に関して、いかなる表明、保証、またはその他の保証も行いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsをご覧ください。
