Skip to content Skip to footer
Search

Loading Results

次世代のITインフラ‐ゼロトラスト・アーキテクチャ ゼロトラストの実現に必要な機能および構成の例

1.ゼロトラストは、どのようなソリューションで実現するのか?

前回までに記載した通り、ゼロトラスト・アーキテクチャは概念であり、特定のソリューションを指すものではありません。とはいえ、それを実現する立場であるクライアントからは、「結局、何を使ってどう実現すればよいのか」といった旨のお問い合わせをいただくことがあります。

実際には、各ベンダーがそれぞれのシーズでゼロトラストを解釈していることから、製品/ベンダーによって多様な実現方法があるのが実態です。そのため、一概にソリューションへ紐づけることが困難な側面があるのですが、ここでは「ゼロトラスト・アーキテクチャの実現に求められる機能」を考え、それを実現するための一般的なソリューション例を紹介していきます。

2.ゼロトラスト・アーキテクチャの実現に求められる機能

第1回で述べた通り、ゼロトラスト・アーキテクチャでは、ユーザーやデバイスおよびコンテキストに基づき正当性・信頼性を検証し、その結果に基づきシステムやデータなどへのアクセス可否を判断するという考え方を採用します。そのためには、例えば以下のような機能を具備している必要があります。

ユーザーの正当性・信頼性の検証

  • そもそも正しいユーザーなのか(本来アクセスを許可されているのか)を検証します。これは、ゼロトラストでなくとも既にほとんどのシステムで実装されていますが、ゼロトラスト・アーキテクチャにおいては、IdP(Identity Provider)に一元的なユーザーの認証の仕組みを付与し、その背後でディレクトリサービスに問い合わせを行うような場合が多いです。
  • アクセス者が正しいユーザーであったとして、場合によっては「本当にそのユーザーが意図してアクセスしたものなのか」を検証する必要が生じるでしょう。つまり、正しいユーザーが侵害されたことによる不正アクセスではないかを確認します。これはトークンや生体などを用いた、2要素目以降の認証によって実現されるものです。この認証も、上記同様にIdPで実現するケースが多数を占めます。

デバイスの正当性・信頼性の検証

  • ユーザーと同様、データやシステムにアクセスすることが許可されているデバイスであるかを検証します。クライアント証明書によって認証するケースが多いでしょう。ただし、一概に許可/拒否を判断するだけでなく、仮にクライアント証明書がない場合(私物デバイスなど)でも、特定の行動(読み取り専用など)であれば許可する、などの制御を行う場合もあります。これは、ユーザーと同様にIdPで認証を行い、背後のデバイス管理ソリューション(MDM: Mobile Device Management, EMM: Enterprise Mobility Management, またはUEM: Unified Endpoint Managementなど)に問い合わせることで実現できます。
  • 許可されたデバイスだとして、それが「アクセス許可に足る状態なのか」を検証します。つまり、パッチやパターンファイルが適用されていない、あるいはOSのバージョンが最新ではないなど、許可しているデバイスであっても望ましくない(リスクがある)状態の場合、アクセスさせない、といった判断がなされるべきです。これも上記同様のデバイス管理ソリューションで実現できます。

コンテキストの検証

  • ユーザーやデバイスが認証された状態であったとしても、その行動が適切であるかを検証する必要があります。例えば、社内の機密情報を、許可していないクラウドストレージへアップロードするような動作があった場合、それは遮断または検知されるべきですし、許可しているクラウドもしくはオンプレミスであっても、不審または不正な行動は検知され、アクセス権を剥奪するなどの対応が求められます。この実現にはさまざまな方法が考えられますが、代表的なものを以下に記載します。
    • CASB(Cloud Access Security Broker)を用いて、許可していないクラウドサービス(Shadow IT)の利用を検知・制御、ならびに許可したクラウドサービスにおける行動(データのアップロード、ダウンロードまたはコピー・編集など)を制御
    • IRM/DRM(Information/Data Rights Management)またはDLP(Data Loss Prevention)製品などを用いて、データの持ち出し検知・制御、または有事におけるトレーサビリティを確保
    • SIEM(Security Incident and Event Management)またはUEBA(User and Entity Behavior Analysis)で上記ソリューションやデバイスのログを分析の上、不審な兆候を検知し、その結果に基づき不審なユーザーや端末を遮断
  • ユーザーやデバイスが認証された状態であったとしても、その後に侵害を受ける(マルウェア感染など)可能性もあります。そのため、継続的に状況を監視の上、必要に応じて遮断する必要があります。これにはEPP(Endpoint Protection Platform、アンチウイルスソフト)やEDR(Endpoint Detection and Response)を用います。また、インターネットアクセスの状況を監視・制御するという意味でSWG(Secure Web Gateway、クラウド版プロキシのイメージ)の利用も有効です。

ここまでに記載した内容を簡単にまとめると、以下のようになります(図表1)。こうして一覧化してみると、ゼロトラスト・アーキテクチャは、概念としては新しいものの、その実現に用いるソリューション群自体は目新しいものばかりではないことが分かるのではないでしょうか。

(任意)経路の変更

ゼロトラスト・アーキテクチャでは、特定のネットワーク(企業のLANなど)に参加していることを条件としたアクセス許可を行いません。つまり、自宅やカフェからでも、オフィスからでも、等しくデータやシステムにアクセスできる環境が必要となります。一方、アクセス先のデータやシステムは未だにオンプレミス環境内に存在する場合もあり、インターネット越しにアクセスさせることのリスクがあります。

その場合は、SDN/SD-WAN(Software-Defined Network/WAN)を用いて、アクセス先のシステムに応じて経路を変更するなどの方法が採られる場合もあります。ただし、リバースプロキシなどを用いて、インターネットから安全にアクセスする方法も存在します。

3.ゼロトラスト・アーキテクチャの実現の例

これまでの内容に基づき、ゼロトラスト・アーキテクチャを実現した場合のセキュリティアーキテクチャについて、一例を図示します(図表2)。ただし、冒頭に記載した通り、解釈によって多様な実現方法があることから、これが決して唯一の解ではないことにご留意ください。

いずれにしても、各ソリューションの機能・コスト優位性、既存ソリューションとの互換性・親和性、もしくはグループ会社や海外本社・支社との兼ね合いを踏まえて、各企業で適切なソリューションを検討・選定していくことになります。

ただし、第1回・第2回でも記載している通り、「どのソリューションを用いるか」に先立ち検討すべきことが多くありますので、まずはそれらをクリアした上でソリューションの検討・選定を行うべきであると考えます。

執筆者

神野 光祐

シニアマネージャー, PwCコンサルティング合同会社

Email

{{filterContent.facetedTitle}}


{{filterContent.facetedTitle}}