ゼロトラストとは

ゼロトラストとは、あらゆる通信は信頼できない状況で開始されるという前提に基づいてセキュリティ・アーキテクチャを設計するアプローチです。これは、その通信がファイアウォールの内側で開始されたかどうかで通信の信頼性を判断する場合がある従来のアーキテクチャとは対照的です。より具体的には、ゼロトラストは、暗黙の信頼と一時的な認証に依存するセキュリティ・アーキテクチャのギャップを解消しようとするものです。

ゼロトラストは、世界的な脅威の進化によって支持されるようになり、ネットワーク内のアクティビティは信頼できるものだという長年にわたって前提とされてきたことを見直しています。有能なサイバー犯罪者は内部関係者を募り、インサイダー脅威の機会を増大させ、従来のセキュリティ・アーキテクチャの外殻を超えたところに足がかりを見つけます。また、洗練されたハッキングツールや商用サービスとしてのランサムウェア・プラットフォームも広く浸透しており、金銭を要求する新しい種類の犯罪者やサイバーテロリストが簡単に使えるものが登場しています。これらの脅威はすべて、貴重なデータを盗み出し、ビジネスや商取引を混乱させ、人の生活に影響を与える可能性があります。

このような新たな脅威の状況を前提として、米国連邦政府はゼロトラスト・アーキテクチャへの前進を命じる大統領令を受けており、また、多くの組織がこのアプローチを導入するメリットとそれにかかるコストを比較検討しています。

有名なゼロトラストに関する 2010 年の Forrester Research のレポートで、John Kindervag 氏は、ネットワーク・セキュリティに対する一般的なアプローチである「信頼するが検証する」アプローチを「検証して決して信頼しない」戦略に変えるべきだと主張しました。Kindervag 氏は「ネットワークは、M&M チョコレートのように外はカリカリで中は柔らかめがよい」という、当時一般的であったモットーに異議を唱えました。何十年もの間、組織は、信頼できるネットワークまたは内部ネットワーク (柔らかい中身) をファイアウォールなどのセキュリティ防御 (カリカリの殻) の境界によって外界から分離するように設計してきました。境界の内側にある、またはリモートメソッドを介して接続される個人やエンドポイントは、境界外の個人やエンドポイントよりも高いレベルの信頼を与えられていました。

セキュリティ設計に対するこの「外殻は強固に、中身は柔軟に」のアプローチが理想的なものでないことはほぼ間違いありませんでしたが、現在も存続し続けています。これらのアーキテクチャでは、ユーザー、デバイス、データ、およびその他のリソースの分離は最小限であり、一度ネットワーク内に入ってしまえば中を移動するのは簡単です。サイバー攻撃はこの設計を利用し、まず 1 つ以上の内部のエンドポイントまたは他のアセットにアクセスしてからネットワークを横方向に移動することで、弱点を悪用し、制御された情報を盗み出し、更なる攻撃を開始します。

高度なサイバー攻撃の影響を受けやすいことに加えて、ネットワークが拡大してエンドポイントの数が膨大になると、ユーザーはより多くの場所からよりきめ細かいサービスを使用してより多くのアセットにリモートアクセスするようになり、この不十分なアーキテクチャへの負担が大きくなります。新型コロナウイルスのパンデミック以降、リモートワークが増加し、クラウド環境でのワークロードが増え続けているため、信頼の問題がさらに注目を集めています。

この環境の脆弱性を管理するために、組織は、ネットワーク全体への安全なアクセスを可能にする仮想プライベートネットワーク (VPN) から、アクセスをセグメント化し、特定のアプリケーションやサービスへのユーザー権限を制限する、より粒度が小さいゼロトラスト・ネットワーク・アクセス (ZTNA) に移行しています。このマイクロセグメンテーションのアプローチは、攻撃者の横方向の動きを制限し、攻撃対象領域を削減し、データ侵害の影響を封じ込めるのに役立ちますが、ゼロトラストモデルを導入するには、組織がセキュリティ・アーキテクチャのあらゆる側面に「検証して決して信頼しない」という考え方を適用する必要があります。

ゼロトラストセキュリティの基盤は、境界解除と最小特権アクセスです。これにより、機密データ、アセット、およびサービスが、ネットワーク境界と暗黙の信頼を得ているアーキテクチャに固有の脆弱性から保護されます。

境界解除：組織が地理的な境界によって定義されることはなくなりました。ユーザーはさまざまな場所やエンドポイントから作業し、クラウドや SaaS (Software-as-a-Service) ソリューションなど、多くの場合エンタープライズ IT 組織によって所有または制御されていない 1 つ以上の運用環境からリソースにアクセスします。境界をなくすことで、このように場所に基づく信頼が得られない状況に対処できます。

最小特権：名前または場所に基づいて信頼を継承できない場合、すべての通信は疑わしいものとして扱われます。通信を許可するかどうかの決定はビジネス上の決定であり、そのメリットとリスクを考慮に入れて行われなければなりません。最小特権とは、絶対に必要なリソースのみにアクセスを制限することを指します。すなわち、 あるアクティビティに必要な「最小の」特権です。リソースへのアクセス要求はそれぞれ、ID 管理とリスクベースのコンテキスト認識アクセス制御を使用して動的に検証する必要があります。

ゼロトラスト・アーキテクチャを実装するために、既存のネットワークを広範囲にわたって交換したり、新しいテクノロジーを大量に取得したりする必要はありません。代わりに、フレームワークによって他の既存のセキュリティプラクティスとツールを強化する必要があります。多くの組織はすでにゼロトラスト・アーキテクチャに必要な基盤を持っており、日常業務でそれをサポートするというやり方に従っています。

たとえば、ゼロトラスト戦略をうまく導入するために必要な以下の重要なコンポーネントは、従来のセキュリティ・アーキテクチャの一部としてすでに存在している可能性があります。

• ID 管理とアクセス管理

• 認可

• ポリシー決定の自動化

• リソースへの確実なパッチ適用

• トランザクションのログ記録と分析による継続的な監視

• ヒューマンエラーが発生しやすい反復可能なアクティビティを可能な限り自動化

• 行動分析と脅威インテリジェンスをアセットのセキュリティ向上に使用

実際、ゼロトラストは現在すでにさまざまな規模でさまざまな環境に対して実践されています。その中核となるテナントは、主に既存のセキュリティプラクティスの適用と、組織とプロセスの制御を必要とします。米国国防総省、国土安全保障省、インテリジェンス・コミュニティなどの連邦組織は、セキュリティが文化の中心的な柱であり、ゼロトラスト・セキュリティ・モデルの実装に向けてすでに大きな進歩を遂げています。

ビジネス要件を満たしてデジタル・トランスフォーメーション業務を加速するため、多数の祖域がオープンソース・コンポーネントとサードパーティツールを使用してソフトウェアを開発しています。しかし、ソフトウェア・サプライチェーンに忍び込もうとする悪意のあるアクターがオープンソース・コンポーネントのセキュリティや開発サイクルの早期段階の依存関係を侵害すると、サイバー攻撃やアプリケーションリリースの遅延を招いてしまいます。ゼロトラストアプローチはソフトウェア・サプライチェーンのセキュリティ保護にとって重要で、修復コストが比較的安価ですむ早期段階で問題を検出できます。

組織はセキュアなオープンソースコードを使用し、セキュリティをコンテナイメージに組み込み、CI/CD パイプラインを強化し、アプリケーションをランタイムで監視することで、サプライチェーン攻撃のリスクを最小化できます。

セキュリティモデルとしてのゼロトラストは、Bell-LaPadula のような形式が整っていて制御されたアクセスモデルとは対照的に、抽象的な用語で説明されることがよくあります。さまざまなグループや標準化団体が支持するコンポーネント一式にはさまざまなものがあります。一般的なコンポーネント一式は次のとおりです。

• ユーザーおよび非個人エンティティ (NPE) を識別する単一の強力な ID ソース

• ユーザーおよびマシン認証

• ポリシーへの準拠やデバイスの状態などの追加のコンテキスト

• アプリケーションまたはリソースにアクセスするための認可ポリシー

• アプリケーション内のアクセス制御ポリシー

これらのコンポーネントは主に、デフォルトの「すべて拒否」および「例外による許可」を使用して ID ベースのアクセスポリシーを実装する方法に焦点を当てています。

ゼロトラストの原則を順守するために、信頼境界は可能な限り小さく保つ必要があります。定義上、境界内では、サブジェクトは信頼され、アクセス制御は省略されるか回避されるか、そうでなければ制限される場合があります。認可は特定のビジネス機能に対してのみ行われるべきであるため、他の機能へのアクセスを許可する境界は狭める必要があります。

システム・アーキテクチャのすべてのセキュリティ境界を、適切なゼロトラスト境界の基準に適合させる必要はありません。不要な IP アドレスのフィルタリング、一部のプロトコルによるネットワークへのアクセスの許可、ソーシャルメディアの使用の制限など、これらの通常の境界はゼロトラストと重複し、セキュリティ戦略における役割を果たす可能性があります。しかし、ゼロトラストの導入における重要な違いは、従来のネットワーク・アーキテクチャの場合のように、通常の境界は信頼できる部分と見なされないことです。信頼できると見なされるのは、ゼロトラストの原則を満たす境界のみである必要があります。

ゼロトラストでは、個別のサブジェクト間の分離を常に維持する必要があります。つまり、任意の 2 つのサブジェクトの間には常に信頼境界が存在するため、すべての通信には多要素認証 (MFA) と直接認可が必要です。2 つのサブジェクトが同じネットワーク上にある (非常に一般的なシナリオ) という理由で暗黙の信頼を与えられることはありません。また、そのような理由で同じ物理的な場所で利用できたり、あるいは同じ基幹業務または統合システムの一部になったりすることもありません。

ゼロトラスト・セキュリティ・モデルは、これらの信頼境界を適用することで機能します。通常、これは、すべてのリソースとのすべての潜在的な通信の間に実施ポイントを挿入することによって行われます。これらの通信は時間の経過とともに変化するため、システムの ID、リソースの状態、およびその他の側面も変化します。このように常に変化し続けるため、ID とリソースを継続的に評価および監視し、認証と認可も臨機応変に実施していく必要があります。

これらの基本を実装するには制約が大きすぎる領域はまだたくさんあります。レガシー・テクノロジーを使い続けている、ビジネスプロセスが未成熟、セキュリティが不可欠なビジネス機能として認識されていないなどの課題は、いずれも一般的によく見られます。

ゼロトラストを導入するには、多くの場合、リーダーとセキュリティ担当者の両方が考え方を変える必要があります。リーダーは、既存の古いセキュリティ・アーキテクチャを維持することのリスクを評価する必要があります。IT および運用技術 (OT) の担当者は、既存の投資を活用してゼロトラストの実装コストを削減できる領域と、新しい投資を優先すべき領域を認識する必要があります。しかし、現実的には、ゼロトラストになることは決してないプロトコルやデバイスが存在します。その場合、それらを交換するか維持するかを決定する必要があります。さらに、一部のシステムがゼロトラストアプローチを完全に受け入れることができない場合、OT の担当者は、緩和のための制御をどうするか、そして代替のセキュリティ制御を適用して露出をさらに削減できるかどうかを自問する必要があります。

ゼロトラストの基本的な前提である「デフォルトで拒否」または「常に検証」への移行には、組織の中で 「シャドー IT」を作成することによってゼロトラストのセキュリティ・アーキテクチャを回避しようとする部門がないようにすること、そしてチームが長期にわたって実装と維持の両方に従事するというコミットメントが必要です。

Red Hat は、組織がゼロトラストの導入を開始できるよう支援します。まず、組織はゼロトラストの実装を理解し、それに全力を傾ける必要があります。一般的なサイバーセキュリティを認識することは、ステークホルダーを前進させる、つまり、現在の脅威環境の性質と、既存のセキュリティプラクティスがどのように重要であり、ゼロトラストの原則に従わなければどれだけ不完全であるかを理解するために重要な前提条件です。これに関するトレーニングと教育の機会として、Red Hat は、Red Hat Open Innovation Labs や他の専門的な Red Hat サービスのエンゲージメントを通じ、カスタマイズされたエクスペリエンスを提供します。