信頼できるデバイスへのアクセスを有効にした後 – オンプレミスとクラウド内のアプリケーションおよびデータソースへのセキュアなルートを作成した後 – 「匿名」デバイスアクセスを防止することでデータソースをロックダウンし始めることができます。
匿名デバイスとは、組織から認可されていないデバイスのことです。これには以下が含まれます:
- 攻撃者のラップトップ
- User Enrollment されていない個人の iPhone
- 配偶者のラップトップ
- カフェの PC
かつてないほど重要となっているのは、信頼できるデバイスのみへのアクセスを制限することですが、「オンプレミス」の境界が消失したクラウドおよびリモートワーク環境では複雑です。とはいえ、Trusted Access ソリューションとアーキテクチャでは、オンプレミスとクラウドを含むすべてのデータソースのロックダウンをサポートする必要があります。
オンプレミス / データセンターリソースのロックダウン
多くの組織は、直接管理下にあるサーバーに多くの機密アプリケーションとデータを保有しています。これらのサーバーはプライベートファシリティまたは適切にセキュアなデータセンターにインストールされています。
幸い、これらのアプリケーションはすでにファイアウォールの背後にあり、オープンな内部アクセスから隠されています。ただし、確認すべき事項が次の通りあります:
- 宛先サーバーからマップされたパブリック IP(ISP 発行の CIDR 範囲内)を削除してください。サーバーはプライベート IP アドレスのみを通じてアクセス可能である必要があります。
- パブリック IP アドレスからサーバーの内部 IP アドレスへの接続をマップする 1 対 1 NAT またはファイアウォールのピンホール例外を削除してください。これは HTTP や RDP などのリスクの高いプロトコルに特に重要です。
- アプリケーションが特に機密の場合は、ネットワーク ACL(Access Control List)をサーバーまたは LAN に設定して、アプリケーションのインバウンド接続を Jamf Subnet からのみ許可してください。これは IPSec インターコネクトの暗号化ドメイン設定で定義されます。
信頼できるユーザーとそのデバイスは Custom IPSec Interconnect Gateway を通じてこれらのリソースにアクセスします。これは Jamf Trust がデバイスにデプロイおよび有効化されると、シームレスにアクセス可能になります。
Infrastructure as a Service(IaaS)リソースのロックダウン
Infrastructure as a Service は、サードパーティのベンダーが提供するクラウドベースのサービスとして定義され、物理インフラストラクチャを管理することなくアプリケーションを実行してデータを保存することができます。市場で最も一般的な IaaS プラットフォームは Amazon Web Services、Google Cloud Platform、および Microsoft Azure です。
これらの環境内のリソースへのアクセスを制限することは、実はオンプレミス / データセンターリソースと非常に似ています。リソースは通常、IaaS プロバイダー内のプライベート仮想ネットワーク上に設定されているためです。しかし、大きな違いはアプリケーションとデータリソースが公開されることがはるかに一般的だということです。意図的であれ偶然であれ(実行するのが簡単なため!)、このような過度にオープンなアクセスが最近の多くの重大なハッキングの根本原因となっています。
信頼できるユーザーとデバイスは、以下のいずれかのインターコネクトオプションを使用してこれらのリソースにアクセスできます:
- AWS Interconnect
- Azure Interconnect
- Custom IPSec Interconnect Gateway
- Jamf Internet Cloud Gateway からのみ IaaS アクセスポリシーを介したインバウンドアクセスを制限し、他のすべての接続をブロックしてください。
- macOS の AWS Verified Access を設定して、マネージドおよび準拠したデバイスへのアクセスを制限してください。
Software as a Service(SaaS)リソースのロックダウン
Software as a Service は、購入したが運用を所有していないアプリケーションとして定義されます。一般的なビジネス SaaS サービスには Microsoft 365、Salesforce、Slack、Box、および Zoom が含まれます。組織が少なくとも 1 つの SaaS アプリを持ち、それに機密な企業データが含まれている可能性があります!
しかし、SaaS アプリの基盤となるインフラストラクチャ(ネットワーク接続を含む)に対するネイティブな制御がないため、認可されたユーザーおよびデバイスを識別するために使用できるアクセス制御を提供する(または提供しない)ことは SaaS プロバイダーの判断に委ねられます。
一般的に、SaaS アプリへのアクセスをロックダウンするために利用できる 2 つのテクニックがあります:ソース IP またはアイデンティティプロバイダー(IdP)を使用します。
ソース IP アドレスの使用
一部の SaaS プロバイダーでは、個々の顧客が SaaS アプリケーションまたはサービスにアクセスするために自分の顧客テナントにログインすることが許可されるソース IP アドレス範囲を定義できます。比較的稀ですが、ソース IP ロックダウンは Jamf Private Access インフラストラクチャを通じて接続するデバイスからのアクセスのみを許可する信頼できる方法です。
Jamf の共有グローバル IP アドレスまたは Custom IPSec Interconnect Gateway の反対側のパブリック IP を使用できます。
これの強力な例は Access Client Access Rules を使用して Microsoft Exchange 接続を Private Access 対応デバイスのみに制限する ことです。
アイデンティティプロバイダーの使用
ほとんどの SaaS プロバイダーは Single Sign On をサポートしており、これは個別の認証情報セットに依存する代わりに、組織のアイデンティティプロバイダー(例:Okta、Azure AD)を使用してそのアプリケーションへのアクセスを許可または拒否します。これはユーザーアイデンティティに優れていますが、SaaS プロバイダーはめったにデバイスアクセス制御を提供しません。
幸い、アイデンティティプロバイダーはデバイスレベルの認識をサポートしており、これを使用して認可されたデバイスと認可されていないデバイスを区別できます。
Jamf ソース IP 経由
市場の 3 つの主要な IdP は、ログインの際のソース IP アドレスを基準として検討するサインオンアクセスポリシーを定義することをサポートしています。
この基準を使用して、Jamf のクラウド IP アドレスを使用して、着信ログインが Private Access がデプロイされアクティブ化されたデバイスから発信されたかどうかを識別できます。不正なデバイスは Jamf Security Cloud に属するソース IP を提示しないため、IdP のアクセスポリシーによってブロックされます。
お使いの IdP でこれを設定するための詳細は、以下のガイドをご覧ください:
- Okta: Restricting Login Access
- Microsoft Entra ID: Restricting Login Access
- Google Workspace: Restricting Login Access
この体験がどのようなものかは、ここにある BYOD デモビデオで確認できます。
IdP エンドポイントアプリ/エージェント経由
一部の IdP は、ログインプロセスの一部としてデバイスアイデンティティと認証を提供するために使用できるエンドポイントアプリ/エージェントを提供しています。この方法はソース IP を使用するより優れていますが、追加のデプロイメントとアクティベーションの考慮事項と複雑性が必要です。
- Okta: Managed Devices および Add an Authentication Policy(特に「Device Management」を基準として使用)を参照してください。
- 注:Okta Identity Engine(OIE)が必要です
- Microsoft Azure AD: Device-based Conditional Access Policies を Jamf Pro および Microsoft 条件付きアクセス統合と一緒に使用してください