マクニカ版ゼロトラスト①:都度判断を行うモデル
はじめに
昨今、ゼロトラストという言葉を耳にする機会が多くなりました。企業システムやデータのクラウドへの移行、従業員の働き方の変化など様々な要因によるものだと考えられます。
また、COVID-19の影響によりテレワークという用語が世間で浸透し、多くの企業がテレワークを経験したことで、従来の境界型ネットワークの持つ課題を再認識し始めたこともその一端でしょう。
一方でゼロトラストがカバーする範囲は広く、どこから手を付けてよいかわからないという方も多いのではないでしょうか。ゼロトラストはあくまでも概念であり、ゼロトラストを実現するための手法は企業によって異なりますが、それゆえ検討が難しいとも言えます。
ゼロトラストシリーズの第1回目である本記事では、ゼロトラストを実現する際に重要となる、「ユーザーやデバイスの状態に応じて動的にアクセス判断を行う方法」について、弊社取扱製品を例として実際にどのように実現するか、検証結果を交えて記載します。
目次
・境界型ネットワークからゼロトラストへ
・ゼロトラストを実現するための要素
・動的制御(コンディショナルアクセスコントロール)をどのように実現するか
-パターン1 Okta × CrowdStrike × Splunk
-パターン2 Okta × Pulse Secure × Vectra × Splunk
-パターン3 Okta × CrowdStrike × Cato × Box × Splunk × Exabeam
・まとめ
境界型ネットワークからゼロトラストへ
ゼロトラストネットワークの対比として、従来型のネットワークは、境界型または境界防御型ネットワークと呼ばれることがあります。企業は、所有するネットワークにFWを設け、社外と社内を隔てる境界を作り、その境界をまたぐ通信に様々なセキュリティ対策・投資を行ってきました。必然的に企業システムやデータは、企業が所有するデータセンターに集中し、境界の内側に存在する社内ネットワークは基本的には信頼されたネットワークとして位置づけられ、ユーザーは企業システムやデータへのアクセスをその信頼のもとで行うことができました。
企業は境界の外側に存在する社外のユーザーに対してはVPNを提供し、ユーザーは社外から社内ネットワークへ安全にアクセスすることができました。
しかし、企業システムやデータのクラウドへの移行、働き方の変化により、これまでは少数だった社外のユーザー数の増加など、様々な要因により境界型ネットワークの課題も明らかとなってきました。
そこで、これらの環境の変化への適応手段として、ゼロトラストが注目されています。
ゼロトラストでは、従来の境界型ネットワークのように社内ネットワークを全面的に信用するのではなく、ユーザーやデバイスの状態を常にチェックし、それらの情報をもとに通信を信頼するかしないかを判断することが求められます。ユーザーが社内・社外どちらにいても、ユーザーやデバイスの状態が適切であるかを確認する必要があり、オンプレ・クラウド問わず一元的な認証を行うことや、社内・社外のアクセス元を問わず同じ経路を用意するなど、ゼロトラストを実現するためにはいくつかの要素が必要となります。
ゼロトラストを実現するための要素
ゼロトラストを実現するための要素を分類すると、大きく分けて以下の4点があげられます。
-
ユーザー認証
-
エンドポイントセキュリティ
-
ゼロトラストアクセス
-
ログ解析・自動化
これらの要素はそれぞれを組み合わせることに大きな意味があります。IDaaSやEDR、SASEやSIEMなど様々な要素を組み合わせることで、企業がゼロトラストに求めるものを実現させることが可能となります。
動的制御(コンディショナルアクセスコントロール)
ゼロトラストでは社内や社外といったネットワークを基準にして信頼性を確保するのではなく、ユーザーやデバイスの状態に応じて信頼するかしないかを柔軟に判断し、企業システムへのアクセス可否を制御することが求められます。また、一度認証に成功した後も継続的にユーザーやデバイスの状態を把握し、ユーザーや端末の不正な挙動を検出した際はアクセスを禁止するといった動的な制御が求められます。
ここからは、具体的に動的制御をどのように行うべきか?を、弊社取扱製品を例として見ていきたいと思います。
パターン1 Okta × CrowdStrike × Splunk
IDaaSを使用することで企業は認証の一元管理や多要素認証を実現することが可能となります。また、EDRを使用することでデバイスの不正な挙動を検知し、場合によっては端末を隔離することも可能です。しかし、EDRによってデバイスを隔離することができたとしても、そのユーザー(あるいは攻撃者)が、他のデバイスからアクセスを試みた場合はアクセスが許可されてしまうことが予想されます。ここではSIEMをハブとしてEDRの検知結果とIDaaSでの制御を紐づける動作を見ていきます。
カテゴリ | 製品 |
IDaaS | Okta |
EDR | CrowdStrike |
SIEM | Splunk |
このシナリオでは、企業システムへのアクセス時の認証はOktaで一元管理された状態となっており、CrowdStrikeはデバイスの不審な挙動を検知します。Okta、CrowdStrikeそれぞれのログはSplunkへ集約されます。Splunkではアラート機能を利用し、特定の条件(例えばSeverityがCriticalなど)に合致した場合にOktaのAPIを実行するよう設定を行います。
実際の動作について、CrowdStrikeからの検知結果を受けてSplunkからOktaのAPIを実行し、該当ユーザーを隔離グループへ変更することに成功しました。隔離グループへ変更されたユーザーは、Oktaで認証を行うことができなくなるため隔離状態を解除するために管理者へ問い合わせるなどの対処を求められます。
この連携はシンプルなものとなりますがSplunkのアラート機能を活用し、ユーザーやデバイスの状態に応じて動的に制御を変更することが可能であることがわかりました。
しかし、Okta上でユーザーの隔離を行った場合に効果を発揮するのは、ユーザーが次回認証を行ったタイミングとなり、すでに認証済みのユーザーには効果が無い点が課題と考えられます。
パターン2 Okta × Pulse Secure × Vectra × Splunk
パターン1の連携では、「すでに認証済みのユーザーをどのように制御するか」という点が課題であることがわかりました。ゼロトラストを実現する際に、動的制御は素早く実行されることが望ましく、検知した段階で即時に通信を遮断することが理想と言えます。
パターン2では、パターン1で見えた課題、「認証済みのユーザーへの制御をどのように行うか」についてみていきます。
カテゴリ | 製品 |
IDaaS | Okta |
SSL-VPN | Pulse Secure |
NDR | Vectra |
SIEM | Splunk |
このシナリオでは、VPN接続時のユーザーの不審な通信をNDRであるVectraで検知し、パターン1と同様にSplunkのアラートを使用してOktaのAPIを実行し、ユーザーの隔離を行います。加えて、SplunkからPulse SecureのAPIを実行し、現在接続中のユーザーのセッションを切断することで、不審なユーザーを素早くネットワークから排除することを目指します。
ユーザーはVPNセッションを切断されたため再認証を試みますが、Okta上で隔離されているためVPNの再接続が拒否されます。
パターン1ではSplunkからの連携先がIDaaSであるOktaだけであったのに対して、パターン2では、通信経路となっているPulse Secureのセッションを切断する動作が追加されています。これにより、検知後即座に接続済みのユーザーを排除し、ユーザーの次回認証を待たずに素早く不審なユーザーを制御することが可能であることがわかりました。
パターン3 Okta × CrowdStrike × Cato × Box × Splunk × Exabeam
パターン2までで、Splunkのアラート機能を活用して動的な制御が行えることが見えてきました。しかし、収集するデータソースの量が多くなるにつれて、制御を行う際の判断も複雑化することが予想されます。そこで、パターン3ではUEBAを使用し機械的に判断することで、複雑な構成において動的制御を簡易に実現できるかを考察します。
カテゴリ | 製品 |
IDaaS | Okta |
EDR | CrowdStrike |
SASE | Cato Networks |
SIEM | Splunk |
SaaS | Box |
UEBA | Exabeam |
このシナリオではEDR、IDaaS、SASEからログを収集してSplunkへ集約します。また、Exabeamを使用してSplunkへ収集したログからユーザーの振る舞いを分析し、スコアリングを行います。スコアに閾値を設け、一定以上のスコアに達した場合、Splunkへ通知し、SplunkからOktaやBoxのAPIを実行しユーザーの動的な制御を行います。
Exabeamを使用することでユーザーの挙動からスコアリングを行い、その結果に応じてIDaaSやSaaSのAPIを実行し動的制御が可能となります。例えば、退職を控えたユーザーが社内の機密情報を外部ストレージに持ち出そうとするなどといった不審な挙動を検知した場合、スコアが追加され一定以上のスコアに達した場合に、制御を行うといった形になります。
パターン1、パターン2では、どのような検知が行われた場合にどのような対処を実施するかをSplunkで個別に定義していたのに対して、パターン3ではExabeamを使用してユーザーの挙動から機械的にスコアリングを行うことで、動的制御を実現させる際の判断に要する手間を軽減できることがわかりました。
まとめ
ゼロトラスト実現の鍵の一つである動的制御について、ここまでの内容で以下が見えてきました。
- SplunkなどのSIEMは連携のハブとして適している
- 動的制御を行う際のポリシー施行ポイントには、IDaaSやSaaSアプリ、ネットワーク機器など複数個所が考えられる
- 一方で、動的制御ポリシーを複数個所に適用する場合、その判断や連携について、人力で行うことは難易度が高まる可能性がある
- UEBAなどの機械による判定を効果的に使用して、ポリシーの策定に役立て、動的制御を実施することが運用上望ましい
いかがだったでしょうか。本記事が、読者の皆様がゼロトラストを検討される際の参考となれば幸いです。
------------------------
【ホワイトペーパー:"絵に描いた餅"はもういらない 検証から見えてきた現実的なゼロトラストの最適解】
今回は、ゼロトラストがなぜ求められているのかについて改めて振り返りながら、 ベンダが語る"都合のいい"ゼロトラストに踊らされないための、 その考え方について紐解いていきたい。
【マクニカネットワークスのゼロトラストソリューションをご紹介】
------------------------