# ゼロトラストとは

社内ネットワークや会社の端末という理由だけで信頼せず、情報やアプリごとに利用者や端末を確認し、必要なアクセスを許可する考え方です。

## ゼロトラストとは

ゼロトラストは社内ネットワークへの接続や会社の端末の使用だけを理由にアクセスを信頼しないセキュリティの考え方です。情報やアプリごとに利用者や端末を確認し、必要な操作を許可します。[1つの情報やアプリへの許可で、別の情報やアプリへのアクセスを自動的には認めないこと](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)も、ゼロトラストの基本原則の1つです。

例えば社内の人事データに接続するとき、本人と端末を確認したうえで、担当業務に必要な閲覧や変更だけを許可します。建物への入館証を所持していても、すべての部屋に入室できるわけではないのと同じです。

ゼロトラストとの違いを押さえておきたい技術に、既存の通信網の上に限られた相手との[仮想的なネットワークを構築する](https://csrc.nist.gov/glossary/term/virtual_private_network)VPN（Virtual Private Network）があります。主に通信路を構築して保護するVPNに対し、ゼロトラストは情報やアプリごとにアクセスを判断するための考え方です。

![社内と社外の人事担当について、本人と端末を確認した後に情報と操作の権限を判定します。人事データの閲覧が許可されても、別のデータベースへのアクセスが自動的に許可されるわけではなく、別途判定する例です。](https://media.marketing.kdotdev-tunnel.org/glossary-zero-trust-e1dc34d7feb4eab6db9ff8286b7ea3e7d06ad2ef1c41f1332507e56a1d4ce7e4.png)

## 社内からの接続でも本人と端末の状態を確認する理由

社内ネットワークへの接続だけを許可の条件にする場合、パスワードが盗取されたり、端末が不正なプログラムに感染したりすると、接続先の情報が不正に利用されるおそれがあります。

また、業務では社外からシステムに接続することもあります。SaaS（Software as a Service）と呼ばれる、事業者のクラウド上で稼働するソフトウェアをネットワーク経由で利用するサービスに、情報を保存することもあります。[社外からの接続やSaaSへの情報保存がある場合、社内ネットワークの内外だけを基準にしては必要な保護を網羅できないことがあります](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)。

![社内接続だけを許可の条件にする場合、流出したパスワードを利用して社内へ接続し、業務情報が不正利用されるおそれがあります。](https://media.marketing.kdotdev-tunnel.org/glossary-zero-trust-72b12ac14f65d59ca3f6390bd3fc2ff2dba5705e49c6d682b2ac94f905c428f1.png)

ゼロトラストでは情報とアプリを保護対象として、利用者・端末・必要な操作を基にアクセスの可否を決定します。[アクセス許可の判断に利用者や端末の情報を利用し、利用中も方針に応じてアクセスを再評価します](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)。変化が利用中のログインへ反映されるかどうかや時期は、サービスと設定によって異なります。

社内からの接続も確認対象ですが、操作のたびに必ずパスワードを入力させるという意味ではありません。

## VPNへの接続だけで利用者の担当外の情報へのアクセスを防止できるか

VPNへの接続だけでは必要のない情報へのアクセスまで防止できるとは限りません。接続後にどの情報やアプリへアクセスできるかも確認します。VPNは例えば社外の端末と社内のVPN装置の間に暗号化した通信路を構築します。[VPN装置が本人確認や接続先の制限を担う構成](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-46r2.pdf)もあり、VPNなら誰でも社内のすべてに接続できるわけではありません。実際の到達範囲は設定によって異なります。

一方、VPNに接続できた利用者へ広範な接続を許可し、その先のアプリやデータの権限を確認していなければ、必要のない情報にも到達するおそれがあります。既存のVPNを利用しながら、接続先の範囲を制限し、アプリ側でも利用者ごとの権限を設定できます。ゼロトラストを実践するためにVPNを一律に廃止する必要はありません。

![社外端末とVPN装置の間は暗号化されます。VPN装置で認証や接続先の制限も可能で、その先のアプリでは業務情報への権限を確認する例です。](https://media.marketing.kdotdev-tunnel.org/glossary-zero-trust-ba1485c8cd1df1ef00b361fe626955f444fb4f553f470938666a406b2e06af50.png)

## 本人確認とアクセス権を区別する

認証は利用者が誰かを確認することです。認可は確認した利用者が対象の情報を閲覧・変更できるかを判断することです。ログインできることと、情報を閲覧・変更できることは別に判断します。担当者には業務に必要なデータを許可し、担当外の人には許可しないようにします。例えば前述の人事データなら、ログインできる人すべてに変更まで認める必要はありません。

認証を強化する仕組みの1つが、異なる種類の要素を併用して本人を確認する多要素認証です。例えばパスワードと、利用者が所持する端末の認証アプリで発行する確認コードを併用します。ただし、1回限り有効なワンタイムコードを手入力する方式では、[コードが偽サイトから攻撃者に中継される可能性があります](https://pages.nist.gov/800-63-4/sp800-63b.html)。

シングルサインオンは1回の認証で複数のサービスを利用しやすくする仕組みです。多要素認証とシングルサインオンのどちらを利用していても、各サービスの情報と操作に対する権限の管理は必要です。

![利用者に対する認証で本人を確認し、認可で人事情報に対してどの操作を許可するかを判断します。](https://media.marketing.kdotdev-tunnel.org/glossary-zero-trust-e6fd574c2ecfc61c70630a031559cbf30be28e755a8a52e42cd6044f7eb004ad.png)

例えば人事情報を管理するSaaSでは、担当者だけに閲覧を認め、情報を更新できる人をさらに限定します。閲覧とダウンロードの権限を個別に設定できるかを確認し、できない場合は共有する対象を再検討します。

端末の管理状態を条件にできるサービスなら、組織が管理し必要な更新を適用した端末だけを許可する設定も選択できます。

異動や退職では不要になった権限を削除します。[認証基盤でアカウントを停止しても利用先が発行したログイン状態が継続する場合](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)があるため、権限を削除した際にも、利用中のログインを終了する方法と反映をサービスごとに確認します。

人の利用だけでなく、顧客データを参照する自動連携にも必要な操作だけを許可し、利用しなくなれば停止します。

![自動連携から顧客データには必要な操作だけを許可し、不要になった連携は停止します。](https://media.marketing.kdotdev-tunnel.org/glossary-zero-trust-08f81779cfa1615d9d9071e64470850a7a9bad5d9213cdfd0d9bb706222d9b25.png)

## どの情報からゼロトラストの対策を始めるか

最初は機密情報を管理するサービスや、多くの設定を変更できる管理者アカウントから対象を選択します。侵害された場合の影響が重大で、誰にどの権限が必要かを決定できる対象を優先します。公開済みの情報を閲覧するだけの操作より、その情報を変更・削除できる権限の管理を先に検討します。

対象を選定した後は、[既存環境を調査しながら段階的に機能を追加します](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-35.pdf)。まず、対象の情報とアプリ、利用者、端末、現在の権限を把握します。次に、既存のサービスで多要素認証や権限の制限を設定できるか確認します。選定した対象と利用者の範囲で試行し、必要な操作ができるか、許可していないアクセスが拒否されるかを点検してから拡大します。

![情報、利用者、端末と権限を把握し、対象を選定して限定した範囲で試行します。必要な操作の許可と許可していないアクセスの拒否を確認できた場合は対象を拡大し、できない場合は拡大を保留します。](https://media.marketing.kdotdev-tunnel.org/glossary-zero-trust-762083625f097088d24dd3a7b98bc1aa6530439701e2f4e826bb23aa3a596823.png)

旧来のシステムが端末の状態確認や、利用者のログインを管理する認証基盤との連携に対応していない場合は、一度に移行せず、既存の接続制限や認証方法を確認します。利用者と接続先を限定できるVPNなどがあれば維持し、代替手段を試験してから移行します。必要な制限ができない場合は、そのシステムに保管する情報や利用者を限定できるか、業務への影響も考慮して判断します。

## 運用時の負担と限界

導入後も利用者と端末の登録、現在の担当と権限の対応を確認する棚卸し、アクセス記録の確認、例外の判断に担当者の工数がかかります。サービス間の連携や追加機能に費用が発生する場合もあります。導入時には、[資産や利用者の役割の把握不足、製品間の連携、担当者の技能](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-35.pdf)が課題になることもあります。

アクセス記録には個人や端末に関する情報が含まれるため、[記録の取得に伴うプライバシーのリスクを特定し](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)、収集の目的、閲覧できる担当者、保存期間を決定します。記録は攻撃者の標的にもなるため、[記録自体も保護します](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)。

設定が厳しすぎると正当な利用者も業務を継続できなくなります。認証基盤の停止や端末の故障も想定し、管理担当への連絡先、本人確認、アクセスの復旧手順を事前に決定します。[権限のあるアカウントが侵害された場合は、そのアカウントに許可された情報が利用されるリスクも残存します](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)。

![権限と現在の担当業務の対応確認、アクセス記録の閲覧者と保存期間の決定、認証基盤の停止に備えた復旧手順の用意を並列に示します。](https://media.marketing.kdotdev-tunnel.org/glossary-zero-trust-829a127b347fa33b640dbc9e6f312def6ec76b6b657052aa97c02d4a3bb6718d.png)