ABACは、CUIアクセス制御を役職やグループだけに依存させないための考え方です。主体、客体、操作、環境条件を見て判断することで、CUIの保護をより細かく、より説明可能にできます。

はじめに

CUIを扱う環境では、「誰がアクセスできるか」を単純なグループ権限だけで決めるのは危険です。

設計部だからすべての図面を見られる。品質保証部だからすべての試験データを見られる。管理者だからすべてのストレージにアクセスできる。このような粗い権限設計では、CUIの配布制限、契約単位の分離、プロジェクト単位のneed to know、国境を越えるアクセス制限を表現しにくくなります。

そこで重要になるのが、ABACです。

ABACは、Attribute-Based Access Controlの略です。属性に基づいてアクセスを判断する考え方です。

結論

ABACは、CUIアクセス制御を「所属グループ」だけでなく、「誰が、何に、どの操作を、どの条件で行うのか」という文脈で判断するための仕組みです。

NIST SP 800-162は、ABACを、主体、客体、要求された操作、場合によっては環境条件に関連する属性を評価し、ポリシーやルールに照らして認可を決定する論理アクセス制御方法として説明しています。

CUIの文脈では、ABACは、CUIカテゴリ、契約番号、プロジェクト、ユーザー属性、端末状態、場所、時間、認証強度、配布制限を組み合わせてアクセスを制御するために役立ちます。

RBACだけでは足りない理由

従来よく使われるアクセス制御はRBACです。Role-Based Access Control、つまり役割に基づくアクセス制御です。

RBACは有効です。設計者、管理者、品質保証、プロジェクトマネージャー、外部委託先といった役割で権限を設計できます。

しかし、CUIではRBACだけでは荒すぎることがあります。

同じ設計者でも、契約Aの設計者と契約Bの設計者は異なります。同じ品質保証担当でも、CUI//SP-CTIに該当するデータを扱える人と、一般的な品質記録だけを扱う人がいます。同じ管理者でも、CUI本文にアクセスする必要がある管理者と、基盤だけを管理すればよい管理者がいます。

RBACは「役割」を表現するのは得意ですが、「条件」を表現するのは苦手です。

ABACはこの弱点を補います。

ABACの4つの属性

ABACでは、主に4種類の属性を見ます。

属性 例
主体属性 ユーザー、所属、役割、プロジェクト、雇用形態、国籍・居住地、承認状態
客体属性 データ種別、CUIカテゴリ、契約番号、顧客、ラベル、配布制限、機密度
操作属性 閲覧、編集、ダウンロード、印刷、共有、削除、復号、エクスポート
環境属性 端末準拠、MFA強度、接続元、場所、時間、リスクスコア、ネットワーク状態

CUIアクセス制御では、この4つを組み合わせます。

たとえば、次のようなポリシーを考えることができます。

「契約Aに割り当てられた設計者は、管理済み端末からMFA済みの場合に限り、契約AのCUI図面を閲覧・編集できる。ただし、外部共有と一括ダウンロードは承認が必要」

これは、単なるグループ権限よりもはるかに現実に近い判断です。

CUIカテゴリと配布制限を属性として扱う

CUI対応でABACが重要になる理由は、CUIが一種類ではないからです。

CUIにはカテゴリがあります。Controlled Technical Information、Export Control、Critical Infrastructure、Privacyなど、情報の根拠や扱いが異なります。また、Limited Dissemination Controlsが付く場合もあります。

NARAのCUI Registryでは、CUIカテゴリや限定配布管理が整理されています。たとえばControlled Technical Informationは、軍事または宇宙用途を持ち、アクセス、使用、複製、修正、表示、開示、配布などが制限される技術情報として説明されています。

このような情報を単なる「社外秘」ラベルで扱うと、実務上の判断が粗くなります。

ABACでは、CUIカテゴリや配布制限を客体属性として扱い、アクセス判断に利用できます。

日本企業におけるABACの重要性

日本企業が米国防衛サプライチェーンに関わる場合、ABACは特に重要です。

理由は、組織境界、法人境界、国境、雇用関係、委託関係が複雑になるからです。

米国子会社の社員、日本本社のIT管理者、日本国内の設計者、海外製造拠点、MSP、SOC、クラウド事業者、顧客側レビュー担当者。これらの主体に対して、単純に「社内ユーザー」「外部ユーザー」と分けるだけでは不十分です。

ABACでは、次のような属性を組み合わせて判断できます。

  • どの法人に所属しているか
  • どの契約に割り当てられているか
  • どのプロジェクトで承認されているか
  • どの国・地域からアクセスしているか
  • 輸出管理上の制限があるか
  • CUIカテゴリに応じた取扱い権限があるか
  • 端末が管理されているか
  • 管理者権限の利用目的が承認されているか

ここで注意すべきなのは、ABACは輸出管理判断そのものではないということです。ABACは、輸出管理や契約条件で決まったルールを、アクセス制御に反映するための仕組みです。

ABACはZero Trustの認可判断に近い

Zero Trustでは、ネットワーク上の場所だけを理由に暗黙の信頼を与えません。NIST SP 800-207も、Zero Trustは静的なネットワーク境界から、ユーザー、資産、リソースへ焦点を移す考え方であると説明しています。

ABACは、このZero Trustの考え方をアクセス制御として具体化します。

「社内ネットワークからアクセスしているから許可」ではなく、「この主体が、この客体に、この操作を、この環境条件で行うことを許可してよいか」を判断します。

CUI保護では、この粒度が重要です。

たとえば、同じユーザーでも、会社支給端末から閲覧する場合と、個人端末からダウンロードする場合ではリスクが違います。同じファイルでも、閲覧と外部共有ではリスクが違います。同じ操作でも、通常業務時間内の単件アクセスと、深夜の大量ダウンロードでは意味が違います。

ABACは、この違いをポリシーに反映できます。

ABAC導入で最も難しいのは属性の品質

ABACの難しさは、技術そのものよりも属性の品質にあります。

どのユーザーがどのプロジェクトに参加しているのか。どのデータがどの契約に紐づくのか。どのファイルがCUIなのか。どの端末が管理済みなのか。どの委託先が承認済みなのか。

これらの属性が古い、曖昧、手入力、未承認であれば、ABACは機能しません。

したがって、ABACを設計するには、次の管理が必要です。

  • IDライフサイクル管理
  • プロジェクト参加者管理
  • データ分類管理
  • 契約番号・顧客情報との紐づけ
  • 端末コンプライアンス管理
  • 外部ユーザー管理
  • 承認ワークフロー
  • 定期レビュー
  • ログ監査

ABACは「細かい権限設定」ではありません。正しい属性を維持するガバナンスです。

実装パターン

ABACを最初から完全に実装する必要はありません。CUI対応では、RBACとABACを組み合わせる現実的な設計が有効です。

たとえば、基本権限はRBACで設計します。

  • CUI設計者
  • CUIレビュー担当
  • CUIプロジェクト管理者
  • CUIシステム管理者
  • 外部委託先

そのうえで、ABACで条件を追加します。

  • 契約番号が一致する
  • CUIカテゴリが許可範囲内である
  • デバイスが準拠している
  • MFAが成功している
  • 場所や国が許可されている
  • ダウンロードや外部共有は追加承認がある

このように、RBACで大枠を作り、ABACで条件を加えるのが現実的です。

よくある誤解

「ABACを入れれば権限管理が楽になる」という誤解があります。実際には、属性管理が必要になるため、最初はむしろ設計負荷が上がります。しかし、その分、後から説明可能で柔軟な制御ができます。

「ABACは大企業向けで中小企業には不要」という誤解もあります。CUIを扱う範囲が小さい企業でも、契約番号、プロジェクト、ユーザー承認、端末準拠といった属性を使うことで、境界を小さくできます。

「属性が多いほど安全」という誤解も危険です。属性が多すぎると運用できません。最初は、契約、プロジェクト、CUIラベル、端末準拠、MFA、外部共有可否など、実務に効く属性に絞るべきです。

本質

ABACの本質は、アクセス制御を静的な所属から、状況に応じた判断へ変えることです。

CUI保護では、「誰であるか」だけでは足りません。「何に対して」「どの操作を」「どの条件で」許可するのかが重要です。

ABACは、CUIをデータ中心に守るための判断構造です。CMMCをチェックリストとしてではなく、CUIの利用を継続的に検証する設計として捉えるなら、ABACは非常に重要な考え方になります。

深掘り：ABACによるアクセス制御を実務判断に落とす

ABACは、役割だけでなく、主体、客体、操作、環境条件の属性を組み合わせてアクセスを判断する方式です。CUI保護では、単に「部門に所属しているからアクセス可能」とするより、案件、国籍・居住性、端末状態、データ分類、時間帯、操作種別を条件に含める方が実態に合います。

ここで重要なのは、概念を知識として理解するだけで終わらせないことです。CMMCやCUI保護の実務では、どの情報を、どのシステムで、誰が、どの権限で、どの条件のもと扱うのかを説明できなければなりません。ABACによるアクセス制御という論点も、最終的にはSSP、資産台帳、データフロー、責任分界、運用証跡のどこかに接続されます。

RBACだけで運用すると、役割が増えすぎるか、逆に大きすぎるロールに権限を集約してしまいます。その結果、CUI案件に関係しない人が同じ部門ロールで閲覧できる、外部委託先に必要以上の操作を許す、といった問題が起きます。

このため、設計時には「対象を狭く見すぎていないか」と「責任を広く曖昧にしすぎていないか」の両方を確認します。前者はスコープ漏れを生み、後者は運用不能な過大スコープを生みます。CMMC対応で重要なのは、すべてを一律に厳しくすることではなく、CUIに影響する経路を特定し、そこに必要な統制を説明可能な形で置くことです。

CMMC / CUI環境での見方

CMMCの文脈では、この論点を単独で扱うのではなく、CUI Asset、Security Protection Asset、Contractor Risk Managed Asset、External Service Provider、Cloud Service Providerとの関係で見ます。CUIを直接扱う資産だけでなく、CUI環境を保護するID基盤、監査ログ、EDR、SIEM、バックアップ、管理端末、ネットワーク制御も、判断対象に入ることがあります。

ABACを設計するには、属性の正確性と所有者を決めることが不可欠です。人事属性、契約属性、案件属性、データ分類、端末準拠、地理的条件を誰が更新し、どのシステムが参照するのかを明確にします。

このとき、「どの製品を使うか」よりも、「その製品がどの要求を、どの範囲で、誰の責任で満たすのか」を先に整理します。クラウドやMSPを利用している場合でも、サービス提供者が担う部分と顧客側が設定・運用・確認する部分は分かれます。したがって、Customer Responsibility Matrixや契約上のサービス範囲を、SSPの記述と一致させる必要があります。

日本企業で起きやすい場面

日本本社の設計部門の中でも、米国DoD案件に参加するメンバーと参加しないメンバーが混在する場合、部門ロールだけでは不十分です。案件属性、CUI属性、アクセス元端末、MFA状態を判断条件に入れる必要があります。

このような場面では、米国側の契約主体、日本側の親会社、現地子会社、外部MSP、クラウド事業者、業務部門が同じ情報に異なる立場で関わります。日本側が「データを直接見ていない」と考えていても、ID管理、端末管理、ログ監視、バックアップ、ヘルプデスク、インシデント対応を担っている場合、CUI環境の保護に影響している可能性があります。

そのため、最初に確認すべきなのは「誰が契約主体か」だけではありません。誰がCUIにアクセスできるのか、誰がアクセス権を付与できるのか、誰がログを見られるのか、誰が障害時に復旧できるのか、誰がインシデント時に顧客へ説明するのかを分解する必要があります。

SSP・証跡・責任分界への落とし込み

属性定義書、ポリシー条件、属性更新ログ、アクセス決定ログ、例外承認、定期レビュー結果が証跡になります。

SSPに書くべきなのは、理想的な方針だけではありません。評価者や顧客が確認したときに、実装状態を追跡できる記述が必要です。たとえば、アクセス制御であれば対象者、対象システム、認証方式、例外条件、レビュー頻度、ログ保存先まで書かなければ、実装の説明としては不足します。

責任分界では、Accountableな主体とResponsibleな主体を分けます。契約上の表明を行う組織、設定を変更する組織、ログを監視する組織、証跡を保管する組織、例外を承認する組織が異なる場合、それぞれを文書化します。ここを曖昧にすると、評価時だけでなく、インシデントや顧客問い合わせの場面でも説明が崩れます。

判断フローとして整理する

ABACによるアクセス制御を実務に落とすときは、最初に定義から入るのではなく、判断の順番を決めます。第一に、対象となる情報や機能がCUIそのものなのか、CUIを保護するための機能なのかを分けます。第二に、その対象がどの契約、どの業務、どのシステム、どの外部サービスに結び付いているかを確認します。第三に、アクセスする主体を人、端末、アプリケーション、サービスアカウント、管理者、外部委託先に分解します。第四に、その主体が実行できる操作を、閲覧、編集、削除、共有、管理、復旧、ログ閲覧に分けます。

この順番で整理すると、曖昧な議論が減ります。たとえば「アクセスできるか」という問いは、閲覧できるのか、ダウンロードできるのか、共有できるのか、管理者として復旧できるのかで意味が変わります。また「自社が責任を持つか」という問いも、設定責任、運用責任、証跡提供責任、契約上の説明責任に分けなければ実務には落ちません。CMMCでは、こうした分解がそのままSSP、CRM、資産台帳、運用手順の質に現れます。

運用成熟度の見方

初期段階では、まず対象と責任を見える化することが優先です。対象システム、CUIの流れ、管理者、外部サービス、例外運用を一覧化し、現状を正直に把握します。次の段階では、ポリシーと実装を一致させます。文書には最小権限と書いているが実際には共有フォルダが広すぎる、ログを取得すると書いているが誰もレビューしていない、という不一致を潰していきます。

成熟した段階では、証跡が日常運用の副産物として残るようになります。アクセスレビュー、変更管理、ログレビュー、例外承認、インシデント対応がチケットやワークフローに組み込まれ、評価前に慌てて証跡を集める必要がなくなります。さらに、事業部門、IT、セキュリティ、法務、輸出管理、経営が同じ境界図と責任分界表を見て判断できる状態になると、制度対応は一時的なプロジェクトではなく、継続的な運用になります。

組織間の責任分界

日本企業にとって特に重要なのは、組織間の責任分界です。米国プライム、米国子会社、日本本社、国内製造拠点、MSP、CSPが関係する場合、CUIの保護状態は単一組織の中だけでは完結しません。誰かが設定を変更し、別の誰かがログを見て、さらに別の誰かが契約上の説明を行うことがあります。この状態を放置すると、評価時には「誰が実装したのか」「誰が確認したのか」「誰が例外を承認したのか」に答えられなくなります。

責任分界は、契約書だけで決まるものでも、システム図だけで決まるものでもありません。契約上の義務、実際の管理権限、運用手順、証跡の所在、インシデント時の連絡経路を合わせて初めて成立します。したがって、ABACによるアクセス制御を扱う記事でも、最終的には「この論点を誰が所有するのか」「誰が実装するのか」「誰が証跡を提示するのか」を明確にする必要があります。

よくあるつまずきと回避策

この論点で最も多いつまずきは、制度上の言葉、技術上の設定、運用上の責任を同じ言葉でまとめてしまうことです。たとえば「アクセス制御」と言っても、本人確認、認可、条件判定、権限付与、権限レビュー、ログ確認、例外承認は別の活動です。どれか一つを実装しても、全体が成立するわけではありません。ABACによるアクセス制御を扱うときも、言葉を細かく分解し、各活動に所有者と証跡を対応させる必要があります。

もう一つのつまずきは、評価や監査を意識しすぎて、現場の業務フローから切り離された文書を作ってしまうことです。CMMCで評価されるのは、文書の美しさではなく、実際にCUIが扱われる場面で保護状態が維持されているかです。したがって、業務担当者がどのタイミングでCUIを受け取り、どのツールで加工し、誰に共有し、いつ削除または保管するのかを、現実の流れとして確認する必要があります。

回避策は、記事で扱う概念を必ず「業務」「システム」「責任」「証跡」の四つに戻すことです。業務上なぜ必要なのか。どのシステムで実現しているのか。誰が判断・実装・レビューするのか。証跡はどこに残るのか。この四つに答えられれば、抽象的な概念は実務で使える設計論点に変わります。

確認すべき問い

  • この論点は、CUIそのものに関係しているのか、CUIを保護する機能に関係しているのか。
  • 対象となる資産、ユーザー、管理者、外部サービスはSSPと資産台帳に記録されているか。
  • その統制は、誰が実装し、誰がレビューし、誰が例外を承認するのか。
  • 証跡はどこに残り、どの期間保持され、評価時に誰が提示できるのか。
  • 日本本社、米国子会社、MSP、CSPの責任境界は契約・CRM・運用手順で一致しているか。

次に読む記事

次は「CUIとクラウドストレージ」です。ABACやData-centric Securityをクラウド上のCUI保護にどうつなげるかを整理します。

参考資料