情シス部門のゼロトラスト導入に向けて#3　権限付与について考えてみよう

最近バズワードになっている「ゼロトラスト」について「会社の指示で情シス部門がゼロトラストを導入しなければならない」、「クラウドにSSOを導入するのと何が違うのか」といった相談がありました。ゼロトラストについてうまく説明できないとしたら、予算を作ることも導入に踏み切ることも難しいと思います。こうした疑問についてNISTやIPAのゼロトラスト・アーキテクチャからラックの考えるゼロトラストについてひもといて行きたいと思います。

すべての通信は、機密性と完全性を保護し、アクセス元に対する認証を提供し利用可能な最も安全な方法で行われる必要があります。そこで前回は、クラウドの普及が進み始めた2016年をモデルケースとして、NISTによるゼロトラストの考え方から「ネットワークの場所に関係なく、全ての通信を保護する」について解説しました。

今回は「企業リソースへのアクセスは、セッション単位で付与する」について、ラックの考えるゼロトラストをお伝えいたします。

NISTの基本的な考え方

NISTによるゼロトラストの考え方

• 1.すべてのデータソースとコンピューティングサービスはリソースとみなす
• 2.ネットワークの場所に関係なく、全ての通信を保護する
• 3.企業リソースへのアクセスは、セッション単位で付与する
• 4.リソースへのアクセスは、クライアントID、アプリケーション、要求する資産の状態、その他の行動属性や環境属性を含めた動的ポリシーによって決定する
• 5.企業は、全ての資産の整合性とセキュリティ動作を監視し、測定する
• 6.全ての資産の認証と認可は動的に行われ、アクセスが許可される前に厳格に実施する
• 7.企業は、資産やネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、それをセキュリティ対策の改善に利用する

出典 PwCコンサルティング NIST SP800-207「ゼロトラスト・アーキテクチャ」の解説と日本語訳

PwCコンサルティングが翻訳したNISTによるゼロトラストの考え方は、端的に言えば1は対象範囲、2は通信保護、3は権限付与、4はポリシー、5は監視、6は認証認可、7は改善活動です。つまり情報セキュリティとは、機密性、完全性、可用性の3つの概念によって構成されていましたが、さらに7つの概念を加えます。

前回は2の通信保護について取り上げました。今回は3の「企業リソースへのアクセスは、セッション単位で付与する」について、クラウドの普及が進み始めた2016年をモデルケースに掘り下げて解説してみましょう。

では、Active Directoryやシングルサインオンなど、「IPA 2016年度 中小企業における情報セキュリティ対策に関する実態調査」の「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」を対象とします。

参考までに、最新の実態調査ではアイデンティティ管理が2.8%に低下していることから、導入する上で何かしらの障壁があることが推測されます。こうした現状を踏まえてひもといていきます。

NISTの考え方に対する現状とのギャップ

NISTの基本的な考え方＜権限付与＞

アクセスが許可される前に、アクセス元の信頼性が評価される。また、アクセスは、タスクを完了するために必要な最小権限で付与されるべきである。これは、この特定のトランザクションについては「最新のいつか」という意味でしかなく、セッションを開始する前、またはリソースとのトランザクションを実行する前に直接発生しない場合もある。しかし、あるリソースへの認証と認可が自動的に別のリソースへのアクセスを許可するわけではない。

出典 PwCコンサルティング NIST SP800-207「ゼロトラスト・アーキテクチャ」の解説と日本語訳

NISTによると、企業リソースへのアクセスは、セッション単位で付与することが必要です。具体的にはパソコンへログオンする際に、パスワードを入力するとユーザーアカウントのログオン・セッションが作られます。このログオン・セッションにひもづいた資格情報で認可されたファイルやフォルダ―など様々な企業リソースへアクセスします。

「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」導入率19.0%

最近は、業務でクラウドサービスを利用することも一般的になってきたと思います。例えばActive Directoryと社内システムを一つのパスワードでログインできるSSOを導入していたとしても、様々なクラウドサービスまではSSOに対応できませんでした。

そこで、アイデンティティ・プロバイダーが提供するIDaaSは様々なクラウドサービスに対応しておりSSOが利用できます。さらにアクセス元の信頼性を評価して認証認可を行います。

IDaaS (Identity as a Service：アイダース，アイディーアース)

クラウド上の様々なサービスの ID 管理を一元的に行うクラウドサービスのこと。SaaS（Software as a Service）等への認証（多要素認証，シングルサインオン）・認可（アクセスコントロール）・ID 管理・ID 連携を行う機能を有している。

• シングルサインオン（認証）
  一度メインの ID 管理システムへサインインすれば，他の複数のサービスやシステムへのサインインを自動で行ってくれる機能のこと。利用者は，サービス毎に ID・パスワードを入力する必要がなくなる。
• アクセスコントロール（認可）
  サービス・フォルダ等にアクセスが可能な利用者や端末，場所等に制限をかけ，管理者の許可を得た利用者のみがサービスを利用できるようにする。
• ID 管理
  アカウント作成や削除及び配属変更時の情報変更を一元管理が行えるサービス。アカウント情報をもつマスターシステムの情報を変更することによりシステム毎に情報を変更する必要がなくなる。

出典 IPA ゼロトラスト導入指南書 ～情報系・制御系システムへのゼロトラスト導入～

参考例：Microsoft ADFS、Okta、HENNGE、Cyber Ark、Ping Identityなど

リスクアセスメントからアクセス制御ポリシーに反映する

では、経済産業省 デジタルプラットフォーム構築 事業報告書を参考に、IDaaSを導入する場合の機密情報の流通の把握と制御についてイメージしてみます。機密情報のデータが流通し得る経路としては、クラウドサービスによってインターネット（Wi-Fi、テザリング経由）を想定します。よって、組織内外からのアクセスや、BYODと呼ばれる業務関連の通信、データアクセス、および組織が所有するアプリケーションを使⽤するために個⼈のデバイスを使⽤すること、さらに認可外のデバイスなども含まれます。

※ IdP：アイデンティティ・プロバイダー

※ netskope：クラウドサービスを可視化・アクセス制御・ポリシー適用により、セキュアに利用するクラウドアクセスセキュリティブローカー（CASB）

※ druva in sync：クラウド上にバックアップを行うエンドポイントのデータ保護ソリューション

そこで、IDaaSの導入に向けて、アクセス元の信頼性を評価して認証認可を行うために、アクセス制御ポリシーについて検討します。具体的には、利用者、端末、場所などから業務で必要となる様々なクラウドサービス等のアクセスを洗い出す必要があります。これは、既に導入されている企業も多いISMS（ISO27000:2014）などを用いてリスクアセスメントを行います。

では、アクセス制御ポリシー作成時に参考となるISMSの情報セキュリティ管理基準「アクセス制御に対する業務上の要求事項」をご覧ください。

情報セキュリティ管理基準

9	9	アクセス制御
9.1	アクセス制御に対する業務上の要求事項
9.1.1	アクセス制御方針は、業務及び情報セキュリティの要求事項に基づいて確立し、文書化し、レビューする。
9.1.1.1	資産の管理責任者は、資産に対する利用者のそれぞれの役割に対して、適切なアクセス制御規則、アクセス権及び制限を、アクセスに伴う情報セキュリティリスクを反映した制御の詳細さ及び厳密さで、決定する。
9.1.1.2	アクセス制御は、論理的アクセス制御と物理的アクセス制御の両面を考慮して決定する。
9.1.1.3	利用者及びサービス提供者には、アクセス制御によって達成する業務上の要求事項を明確に規定して提供する。
9.1.1.4	アクセス制御方針に、業務用アプリケーションのセキュリティ要求事項を反映する。
9.1.1.5	アクセス制御方針には、情報の伝達及び認可に対する方針（例えば、知る必要性の原則、情報のセキュリティ水準、情報の分類）を含める。
9.1.1.6	アクセス制御方針は、システム及びネットワークにおける、アクセス権と情報分類の方針との整合性を考慮して定める。
9.1.1.7	アクセス制御方針には、データ又はサービスへのアクセスの制限に関連する法令及び契約上の義務を反映する。
9.1.1.8	アクセス制御方針に、利用可能な全ての種類の接続を認識する分散ネットワーク環境におけるアクセス権の管理を含める。
9.1.1.9	アクセス制御方針に、アクセス制御における役割の分離（例えば、アクセス要求、アクセス認可、アクセス管理）の方針を含める。
9.1.1.10	アクセス制御方針に、アクセス要求の正式な認可に対する要求事項を含める。
9.1.1.11	アクセス制御方針に、アクセス権の定期的なレビューに対する要求事項を含める。
9.1.1.12	アクセス制御方針に、アクセス権の削除の方針を含める。
9.1.1.13	アクセス制御方針に、利用者の識別情報及び秘密認証情報の利用及び管理に関する、全ての重要な事象の記録の保管を含める。
9.1.1.14	アクセス制御方針に、特権的アクセスを認められた役割を含める。
9.1.2	利用することを特別に認可したネットワーク及びネットワークサービスへのアクセスだけを、利用者に提供する。
9.1.2.1	ネットワーク及びネットワークサービスの利用に関し、方針を設定する。
9.1.2.2	ネットワーク及びネットワークサービスの利用に関する方針は、アクセスが許されるネットワーク及びネットワークサービスを対象にする。
9.1.2.3	ネットワーク及びネットワークサービスの利用に関する方針は、誰がどのネットワーク及びネットワークサービスへのアクセスが許されるかを決めるための認可手順を対象にする。
9.1.2.4	ネットワーク及びネットワークサービスの利用に関する方針は、ネットワーク接続及びネットワークサービスへのアクセスを保護するための運用管理面からの管理策及び管理手順を対象にする。
9.1.2.5	ネットワーク及びネットワークサービスの利用に関する方針は、ネットワーク及びネットワークサービスへのアクセスに利用される手段（例えば、VPN、無線ネットワーク）を対象にする。
9.1.2.6	ネットワーク及びネットワークサービスの利用に関する方針は、様々なネットワークサービスへのアクセスに対する利用者認証の要求事項を対象にする。
9.1.2.7	ネットワーク及びネットワークサービスの利用に関する方針は、ネットワークサービスの利用の監視を対象にする。
9.1.2.8	ネットワークサービスの利用に関する方針は、組織のアクセス制御方針と整合させる。

出典 経済産業省 情報セキュリティ管理基準（平成28年改正版）

以上、情報セキュリティ管理基準から想定されるリスクシナリオに対する対策状況をチェックすることでリスクを網羅的に分析します。このようなリスクアセスメントの方法論と基準は、組織の規模や業種、リスクの性質などに応じて適切に選択する必要があります。また、予算・人的リソース・対策を阻害する様々な要因などを考慮することが必要です。例えば、リスクアセスメント実施のプロセスについてIPAが和訳したNIST SP 800-30「リスクアセスメントの実施の手引き」が参考になります。

ステップ1．リスクアセスメントの準備

• リスクアセスメントの目的と範囲を定義します。ゼロトラストの場合はすべてのデータソースとコンピューティングサービスをリソースとみなし、いわゆる「シャドーIT」など幅広く考慮します。
  参考：情シス部門のゼロトラスト導入に向けて#1　ゼロトラストを考えてみよう
• 組織のリスク管理フレームワークやポリシー、リスクアセスメントの目的や範囲、利用可能なリソースや制約に応じて適切なリスクアセスメントの方法論とツールを選択します。これには、リスクの特定、分析、評価のプロセスや手順、リスクの評価基準や尺度、リスクの文章化や報告の形式などが含まれます。その一つとして、ゼロトラストへの移行をサポートするための道標となるゼロトラスト成熟度モデルを用いることをお勧めします。
• リスクアセスメントのチームを編成します。リスクアセスメントの目的や範囲、方法論やツール、役割や責任、スケジュールや予算などを決めるため、情報システムの所有者や運営者、セキュリティ担当者、利用者、監査人、外部の専門家などから選択します。

ステップ2．リスクアセスメントの実施

• 脅威源を特定する。
  脅威源とは、情報システムに対して悪意や偶発的に脅威事象を引き起こす可能性のある人や組織、自然現象などのことです。情報システムの環境や特性、関連する法令や規制、過去のインシデントや事例、専門家の意見を参考にしながら脅威源を特定します。
• 脅威事象を特定する。
  脅威事象とは、脅威源が情報システムに対して行う可能性のある不正なアクセスや攻撃、破壊や損傷、変更や改ざん、漏洩や盗難などのことです。脅威源の動機や能力、情報システムの脆弱性や素因的条件、情報システムの価値や重要度などを考慮して脅威事象を特定します。
• 脆弱性と素因的条件を特定する。
  脆弱性とは、情報システムに存在する欠陥や弱点、不備や不足などのことで、脅威事象が発生する可能性を高めるものです。素因的条件とは、情報システムの環境や状況、状態や要素などのことで、脆弱性の有効性や影響度を変化させるものです。情報システムの設計や構成、運用や管理、監査や評価などを検査して脆弱性と素因的条件を特定します。
• 可能性を特定する。
  可能性とは、脅威事象が発生する確率や頻度、頻発度などのことです。脅威源の動機や能力、脆弱性と素因的条件の有効性や影響度、過去のインシデントや事例、統計や分析などを利用して可能性を特定します。
• 影響の大きさを特定する。
  影響の大きさとは、脅威事象が発生した場合に、情報システムや組織に及ぼす損失や損害、不利益や不都合などのことです。情報システムの価値や重要度、組織の目標や業務、関係者や利害関係者、法令や規制などを考慮して影響の大きさを特定します。
• リスクを判断する。
  リスクとは、脅威事象が発生する可能性と影響の大きさの組み合わせによって表される、情報システムや組織に対する不確実性や不利益などのことです。組織のリスク管理方針や基準を元に、可能性と影響の大きさの評価結果をリスクマトリックスやリスクスコアなどを用いて比較し、リスクのレベルや優先度、受容度などからリスクを判断します。

ステップ3．リスクアセスメント結果の伝達

• リスクアセスメント結果を伝達するための適切な方法を特定する。
  リスクアセスメント結果を伝達する方法には、文書やプレゼンテーション、ミーティングやワークショップなどがあります。伝達の目的や内容、対象者や規模、期限や頻度などを考慮して、リスクアセスメント結果を伝達する方法を特定します。
• 組織の指定された利害関係者にリスクアセスメント結果を伝達する。
  利害関係者とは、リスクアセスメントに関与したり、リスクアセスメント結果に影響を受けたり、リスクアセスメント結果に基づいて意思決定や行動を行ったりする人や組織のことです。リスクのレベルや優先度、受容度などを明確に伝えます。
• 組織ポリシーと手順に従い、リスクアセスメント結果と、結果を伝達する方法を文書化する。
  リスクアセスメント結果と伝達方法の文書化には、リスクレポートやリスクレジスタ、リスクダッシュボードなどがあります。リスクアセスメントの目的や範囲、方法や手順、参加者や役割、結果や分析、推奨や対策などを記録します。

ステップ4．リスクアセスメントの保守

• リスクアセスメントの見直しと更新のための適切な方法を特定する。
  リスクアセスメントの見直しと更新の方法には、リスクレポートやリスクレジスタ、リスクダッシュボードなどの文書やツールを利用することができます。見直しと更新の目的や内容、対象者や規模、期限や頻度などを考慮して、リスクアセスメントの見直しと更新の方法を特定します。
• 組織の指定された利害関係者と協力して、リスクアセスメントの見直しと更新を行う。
  利害関係者とは、リスクアセスメントに関与したり、リスクアセスメント結果に影響を受けたり、リスクアセスメント結果に基づいて意思決定や行動を行ったりする人や組織のことです。リスクの変化や進捗、効果や問題などを検討します。
• 組織ポリシーと手順に従い、リスクアセスメントの見直しと更新の結果を文書化する。
  リスクアセスメントの見直しと更新の結果の文書化には、リスクレポートやリスクレジスタ、リスクダッシュボードなどの文書やツールを更新することができます。リスクの変化や進捗、効果や問題などを記録します。

このように、ゼロトラスト構成要素を追加や変更する場合は、必ず立ち返りリスクアセスメントを行いアクセス制御ポリシーに反映します。次に、認証、アイデンティティ・ストア、リスクアセスメント、可視化と分析能力、自動化とオーケストレーション、ガバナンス能力の考慮事項を元に、ゼロトラストの成熟度をどのレベルに設定するか判断します。これによってアクセス制御ポリシーを適切に更新します。

ゼロトラスト成熟度モデル

CISAが2021年6月にゼロトラスト成熟度モデルのドラフト版を公開しました。ゼロトラスト成熟度モデルは、5つの異なる柱に沿って実装度合いを表しており、最適化に向けて時間をかけて少しずつ進歩させることができます。5つの柱とは、図で示すように、アイデンティティ、デバイス、ネットワーク、アプリケーション・ワークロード、データです。それぞれの柱には、「可視性と分析」、「自動化とオーケストレーション」、「ガバナンス」に関する一般的な内容も含まれています。この成熟度モデルは、ゼロトラストへの移行をサポートするための道標となるものです。

ゼロトラストへの移行を目指すには、従来の暗黙の信頼ではなく、アプリケーション・ワークロードの要求を満たし、ネットワーク・セグメンテーションの保護を見直す必要があります。これにより従来のネットワーク接続方法が改善されると、リモートユーザーや他拠点からアプリケーションやサービスを直接アクセスすることもできます。この移行プロセスを通じてアクセス制御ポリシーを更新し、具体的にどのような保護を、どこへ導入できるか検討する必要があります。既存の保護機能は、再構築されたネットワーク環境において増強する必要があるかもしれません。つまり、NISTの考え方に対する現状とのギャップを埋めていくことにつながります。このようなことから、段階的にゼロトラストを成熟させていくことがゼロトラストの成熟度モデルの考え方となります。そこで最初の柱となるアイデンティティを見てみましょう。

柱1：アイデンティティ

最初の柱となるアイデンティティとは、ゼロトラストの中核的な構成要素です。ゼロトラストを支える最小権限アクセスは、利用者などのアイデンティティを保証できるかどうかにかかっています。ゼロトラスト成熟度モデルは、単にパスワードを使用してアイデンティティを検証することから脱却し、代わりに、サービスまたはデータとの相互関係からアイデンティティを検証し、継続的に確認するために、さまざまな要素を使用します。

サービスをクラウドに移行する際、ユーザはさまざまなプロバイダー間でIDを持つことになります。これらのアイデンティティを効果的に管理し、セキュリティ保護を全体的に調整するために、オンプレミスのアイデンティティとクラウド環境のアイデンティティを統合する必要があります。しかし、これらの統合されたアイデンティティは、漏えいしたアイデンティティやアイデンティティ・プロバイダーが、より広範な環境へのアクセスを許可する可能性があるため、アタックサーフェスを拡大する可能性があります。これらのことを踏まえ、2016年をモデルケースにしたNISTの考え方に対する現状とのギャップから、ISMSに立ち返り、リスクアセスメントを行い、表の機能項目から、認証、アイデンティティ・ストア、リスクアセスメント、可視化と分析能力、自動化とオーケストレーション、ガバナンス能力の考慮事項を元に、ゼロトラストの成熟度を判断します。

最後に

アクセスが許可される前に、アクセス元の信頼性が評価される。また、アクセスはタスクを完了するために必要な最小権限で付与する必要がありました。具体的には、アクセス制御ポリシー作成するために利用者、端末、場所などから業務で必要となる様々なクラウドサービス等のアクセスを洗い出して、ゼロトラストの成熟度を判断する必要がありました。これらが「企業リソースへのアクセスは、セッション単位で付与する」についての考え方となります。

経験豊富な専門家に相談を

しかし、「IPA 2021年度 中小企業における情報セキュリティ対策に関する実態調査」の「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」ではアイデンティティ管理が2.8%に低下していることから、導入に障壁があることが想定されます。

ゼロトラストの実現には、サイバーセキュリティに関する組織の哲学と文化の変革が必要となる場合があります。よって段階的にゼロトラストを成熟させてください。どんな組織であってもゼロトラストへの道は、たどり着くまでに数年を要する旅となります。

つまり、ゼロトラスト移行にあたっては道に迷わないように、情報セキュリティプランニング（セキュリティリスクの可視化、対策立案、ロードマップ作成）が必要です。また、保護に必要なソリューション（セキュリティ製品やサービス）を導入することになるため、手戻りを防ぐためにも実装経験が豊富なSIベンダーからアドバイスをもらうことをお勧めいたします。

今回は3番目の「企業リソースへのアクセスは、セッション単位で付与する」について解説しました。次回は4番目の「リソースへのアクセスは、クライアントID、アプリケーション、要求する資産の状態、その他の行動属性や環境属性を含めた動的ポリシーによって決定する」について、ラックの考えるゼロトラストをお伝えいたします。