アクセス制御

アクセス制御は、セキュリティに関してユーザーが最初に、そして最も頻繁に経験する点です。 コンピューターや携帯電話にサインインするときや、ファイルを共有したり、アプリケーションにアクセスしたりするとき、ID カードキーを使用して建物や部屋に入るとき目にします。 アクセス制御がセキュリティのすべてというわけではありませんが、非常に重要であり、ユーザー エクスペリエンスとセキュリティ保証がどちらも適切になるよう、適切な注意が必要です。

特定のニーズを満たすアクセス制御戦略を開発する方法を確認するには、次のビデオをご覧ください。

セキュリティ境界からゼロ トラストへ

IT に対するアクセス制御の従来のアプローチは、企業ネットワークへのアクセスを制限し、必要に応じて制御を強化してそれを補うというのが基本でした。 このモデルでは、すべてのリソースが企業所有のネットワーク接続に限定されるため、動的なエンタープライズのニーズを満たすには制限が多すぎます。

リモート ワークの導入が進む一方、ビジネス モデルや顧客エンゲージメント モデル、従業員エンゲージメント、権限付与モデルに関して、クラウド技術を利用してデジタル トランスフォーメーションを進めるようになった今、企業はアクセス制御にゼロ トラストのアプローチを採用する必要があります。

ゼロ トラストの原則は、セキュリティ保証を確立し、継続的に向上させながら、こうした新時代に対応する柔軟性を維持するうえで威力を発揮します。 ゼロ トラストへの移行は一般的に、アクセス制御から始まり、優先的な制御として主要に ID に焦点を当てる一方、重要な要素としてネットワーク セキュリティ技術を引き続き採用します。 ネットワーク技術とセキュリティ境界の戦術は、最新のアクセス制御モデルでも今なお健在ですが、完全なアクセス制御戦略において最優先のアプローチではありません。

最新のアクセス制御

組織は、次のようなアクセス制御戦略を考えなければなりません。

• 包括的で一貫性がある。
• テクノロジ スタック全体にセキュリティ原則を厳密に適用する。
• 組織のニーズを満たせる十分な柔軟性を備えている。

次の図は、複数のワークロード、複数のクラウド、ビジネスさまざまな機密レベル、人とデバイスの両方によるアクセスなど、組織がアクセス制御戦略について考慮しなければならないさまざまな要素を示しています。

優れたアクセス制御戦略は、1 つの戦術やテクノロジにとどまるものではありません。 それぞれのシナリオに適したテクノロジと戦術を採用した現実的なアプローチが必要です。

最新のアクセス制御は、組織の生産性のニーズを満たす必要があり、次のような特性を必要としています。

• セキュリティ: 利用可能なあらゆるデータとテレメトリを使用して、アクセス要求中にユーザーとデバイスの信頼性を明示的に検証します。 このような構成なら、攻撃者が検出されずに正当なユーザーを偽装することは難しくなります。 また、アクセス制御戦略では、許可されていないエスカレーションの排除に重点を置く必要があります。たとえば、ある特権を付与して、それより高い特権の取得を許してしまうことがないようにしてください。 特権アクセスの保護の詳細については、「特権アクセスのセキュリティ保護」を参照してください。
• 一貫性: セキュリティ保証が環境全体で一貫してシームレスに適用されるよう図ります。 これが標準になればユーザー エクスペリエンスが向上し、統一性を欠く、あるいは複雑すぎるアクセス制御の実装に存在する弱点を攻撃者に突かれる可能性がなくなります。 構成の不整合や構成のずれを避けるために、最小限の数のポリシー エンジンを使用する単一のアクセス制御戦略が必要です。
• 包括性: アクセス ポリシーは、リソースとアクセス経路にできるだけ近いところで適用する必要があります。 そのような構成になれば、セキュリティの適用範囲が広がり、セキュリティがユーザーのシナリオや期待にスムーズに適合するようになります。 データ、アプリケーション、ID、ネットワーク、データベースのセキュリティ制御を活用して、価値のあるビジネス資産に近いところでポリシーの適用を促しましょう。
• ID 中心: 利用可能な場合に、ID とそれに関連する制御を優先的に使用します。 ID 制御は、もともとのネットワーク トラフィックからは得られないアクセス要求やアプリケーションのコンテキストを提供します。 ネットワーク制御は依然として重要であり、場合によっては唯一の選択肢ですが (運用テクノロジ環境の場合など)、利用可能な場合は常に ID を第一の選択肢と考えるべきです。 アプリケーション アクセス中に ID 層から発生するエラー ダイアログは、ネットワーク トラフィック ブロックよりも正確で有益です。ユーザーは、コストのかかるヘルプ デスクに電話せずに問題を解決できる可能性が高くなります。

エンタープライズ アクセス モデル

エンタープライズ アクセス モデルは、ゼロ トラストに基づく包括的なアクセス モデルです。 このモデルは、システムへの管理アクセス権を持つ内部および外部のユーザー、サービス、アプリケーション、および特権アカウントによるあらゆる種類のアクセスに対応しています。

エンタープライズ アクセス モデルの詳細については、「エンタープライズ アクセス モデル」を参照してください

既知、信頼、許可

アクセス制御のゼロ トラスト移行について考えるには、認証と認可という静的な 2 段階のプロセスから、既知、信頼、許可という動的な 3 段階のプロセスに移行することだと考えるとよいでしょう。

1. 既知: ユーザーの身元が、申告どおり間違いないと確認する認証のこと。 たとえるなら、政府発行の写真付き身分証明書を確認する物理的なプロセスに相当します。
2. 信頼: ユーザーまたはデバイスが、リソースにアクセスできる十分な信頼性を備えているという検証のこと。 これは、空港の保安検査場で、全乗客についてセキュリティ上のリスクがないかどうかを審査したうえでゲートの通過を許可するプロセスに当たります。
3. 許可: アプリケーション、サービス、またはデータに対して特定の権利と特権を付与すること。 同じようにたとえると、これは乗客の行き先、座席の種類 (ファースト クラス、ビジネス クラス、コーチ)、あるいは荷物料金の要不要などを航空会社が把握することに似ています。

アクセス制御の主なテクノロジ

最新のアクセス制御を実現する主なテクノロジは次のとおりです。

• ポリシー エンジン: 生産性とセキュリティの目標を達成するために、組織が技術的なセキュリティ ポリシーを設定するコンポーネント。
• ポリシー適用ポイント: ポリシー エンジンが決定した集約型ポリシーを、組織のリソース全体にわたって実施するポイント。 リソースには、データ、アプリケーション、ID、ネットワーク、データベースなどが含まれます。

次の図は、Microsoft Entra ID が提供するポリシー エンジンとポリシー適用ポイントによって、セキュリティ プロトコルが既知、信頼、許可のアプローチを実装している過程を示しています。

Microsoft Entra ポリシー エンジンは、次のような他のポリシー適用ポイントにまで拡張できます。

• モダン アプリケーション: 最新の認証プロトコルを使用するアプリケーション。
• レガシ アプリケーション: Via Microsoft Entra アプリケーション プロキシ経由。
• VPN およびリモート アクセス ソリューション: Cisco AnyConnect、Palo Alto Networks、F5、For Et、Citrix、Zscaler など。
• ドキュメント、電子メール、その他のファイル: Microsoft Purview Information Protection 経由。
• SaaS アプリケーション: 詳細については、SaaS アプリケーションと Microsoft Entra ID の統合に関するチュートリアルを参照してください。

データドリブンのアクセスの決定

ゼロ トラストの原則である明示的な検証を行うためには、情報に基づいた決定を行うことが重要です。 ゼロ トラストのポリシー エンジンは、セキュリティについて適切に判断するために、ユーザーとデバイスに関して多様なデータにアクセスできる必要があります。 この多様性があって初めて、これらの特性をより確実に識別することができます。

• 実際のユーザーがアカウントを管理しているかどうか。
• デバイスが攻撃者によって侵害されているかどうか。
• ユーザーが適切なロールと権限を保持しているかどうか。

Microsoft は、さまざまなシグナル ソースからセキュリティ コンテキストを統合する脅威インテリジェンス システムを構築しました。 詳細については、「Microsoft の脅威インテリジェンスの概要」を参照してください。

セグメント化: 分離と保護

組織は多くの場合、アクセス制御アプローチの一環として、内部環境を個別のセグメントに分割する境界線を設けることを選択します。 これは、攻撃が成功した場合の被害を、その攻撃を受けたセグメントに封じ込めることを目的とした構成です。 セグメント化は従来、ファイアウォールなどのネットワーク フィルタリング技術を利用して行われてきましたが、同じ概念は ID やその他の技術にも適用できます。

Azure 環境にセグメント化を適用する方法の詳細については、「azure のコンポーネントと参照モデル」を参照してください

分離: ファイアウォールを避け、後は放置

分離とは、セグメント化の極端な形です。決定的に重要な資産を保護するために必要な場合があります。 分離は、ビジネスに不可欠であり、現在のポリシーと標準の導入が困難な資産に対して頻繁に使用されます。 分離が必要な資産の種類としては、次のような運用テクノロジ (OT) システムがあります。

• Supervisory control and data acquisition (SCADA)
• 産業用制御システム (ICS)

分離の成功と持続を実現するには、人、プロセス、テクノロジの完全なシステムとして設計し、そのうえでビジネス プロセスと統合しなければなりません。 これは、防御を検証して維持するプロセスやトレーニングを行わないまま、純粋に技術的なアプローチとして実施すると、時間の経過と共に失敗に終わるのが一般的です。 静的で技術的な問題とだけ捉えたのでは、「ファイアウォールを設定して後は放置」という罠に陥りやすくなります。

ほとんどの場合、分離の実施にはプロセスが必要であり、セキュリティ、IT、OT (運用テクノロジ)、そして場合よってはビジネス オペレーションなど、さまざまなチームがそのプロセスに従わなければなりません。 分離の成功を決めるのは通常、次のような要素です。

• 人: 従業員、ベンダー、利害関係者の全員に対して、分離戦略と各自の役割についてトレーニングを実施します。 脅威、リスク、ビジネスへの潜在的な影響、期待されていること、実際の手法など、それが重要な理由を扱います。
• プロセス: ベンダー アクセス、変更管理プロセス、例外管理を含む脅威への対応手順など、すべてのシナリオについて、ビジネスおよび技術関係者のために明確なポリシーと標準を設定し、プロセスを文書化します。 構成がずれていないことと、他のプロセスが正しく、厳密に守られていることを監視して確かめます。
• テクノロジ: 許可されていない通信を遮断し、異常や潜在的な脅威を検出して、分離された環境と対話するブリッジングおよび転送デバイス、たとえば運用テクノロジ (OT) システムのオペレーター コンソールなどを強化する技術的な制御を実装します。

詳細については、「資産の保護: ネットワークの分離」を参照してください。

次のステップ

アクセス制御の要件にかかわらず、戦略は適切な基盤に基づいている必要があります。 これらの記事およびクラウド導入フレームワークで提供されているガイダンスは、組織が適切なアプローチを見つけて実装するうえで役に立ちます。

次の内容は、セキュリティ運用の最新化です。