リファレンスアーキテクチャ:合併と買収
概要
CompanYa（CompanYa）は、アメリカ合衆国の北平原にある食品メーカーである。成長を続け、新しいタイプの食品に拡大するために、CompanYaは気候の異なる食品メーカーを追加買収する予定です。買収プロセスの一環として、CompanYaは、買収した企業システムを単一の統合エクスペリエンスに統合するための反復可能な戦略を必要としています。
複数の独立組織間の統合により、多くの技術的課題が生じます。課題は、主に、独立した独立したアイデンティティプロバイダによって承認されたプライベートリソース（CompanyB アプリケーション）への外部ユーザー（CompanyYA ユーザー）へのアクセスを許可することに焦点を当てています。
CompanYaは、合併および買収戦略の基盤としてCitrix Workspaceを使用することに決めました。彼らは、CompanyC、CompanyD、CompanyYEを買収するために同じ戦略を使用しようとしているのです。
成功基準
買収戦略の一環として、CompanYA には、CompanYA と CompanyB リソースにユーザーが迅速かつ安全にアクセスできるソリューションが必要です。成功するために、CompanYA は、包括的なデザインの基礎を形成する成功基準のリストを定義しました。
ユーザーエクスペリエンス
合併・買収ソリューションの最初の側面は、ユーザーのニーズを満たすことです。CompanYA は、設計を成功させるために、次のユーザー関連の基準を特定しました。
| 成功基準 | 説明 | 解決策 |
|---|---|---|
| アプリケーション ライブラリ | CompanyA と CompanyB のユーザーは、他の会社のリソースにアクセスするための一元的な方法が必要です。 | Citrix Workspace |
| ウェブアプリのシングルサインオン | 他の会社からプライベート Web リソースにアクセスする場合、 ユーザーは別のユーザーアカウントやパスワードを覚えて入力する必要はありません。 | Citrix Secure Private Access サービス |
| 仮想アプリのシングルサインオン | 他の会社から仮想 Windows アプリにアクセスする場合、 ユーザーは別のユーザーアカウントやパスワードを覚えて入力する必要はありません。 | Citrix DaaS — フェデレーション認証サービス |
| 統一されたエクスペリエンス | ユーザーの元の会社に関係なく、すべてのユーザーの認証エクスペリエンスが同じになります。 | CitrixアプリケーションDelivery Controller — nFactor認証ポリシー |
セキュリティ
M&Aソリューションの2つ目の側面は、セキュリティニーズを満たすことです。CompanYA は、設計を成功させるために、次のセキュリティ関連の基準を特定しました。
| 成功基準 | 説明 | 解決策 |
|---|---|---|
| アイデンティティプロバイダ | 買収された各組織は、CompanYaのプライマリアイデンティティプロバイダと統合できるまで、個別のアイデンティティプロバイダを維持します。 | CitrixアプリケーションDelivery Controller |
| 多要素認証 | セキュリティが最優先される中、企業リソースの認証保護の別のレイヤーを確保するには、MFA が必要です。 | 現在導入されているソリューションを統合するか、プッシュによる時間ベースのワンタイムパスワードが必要 |
| VPNレスアクセス | 企業リソースは、信頼されていない場所やセキュリティで保護されていない場所から保護する必要があります。マルウェアの侵入を防ぐため、デバイスは内部ネットワークへの直接アクセスを許可されていません。 | Citrix Secure Private Access・サービスと Citrix DaaS |
| 内部の脅威 | 買収に不満がある内部ユーザーが顧客データと知的財産を盗むケースが文書化されています。データのキャプチャと保存は制限する必要がある | 強化されたセキュリティポリシー、アプリ保護ポリシー、セキュリティ分析 |
| 外部からの脅威 | マルチディレクトリ認証を処理するために、CitrixアプリケーションDelivery Controller はワークスペースに認証Webアプリを提供します。CompanYA パブリック向け Web アプリ用の保護レイヤーを追加する必要があります。 | ボット管理とWeb App Firewallを備えたCitrixアプリケーションDelivery Controller |
概念アーキテクチャ
CompanYA は、定義された要件に基づいて、買収戦略のために、次の高レベルの概念アーキテクチャを作成しました。概念アーキテクチャは、すべての要件を満たしているだけでなく、将来的に特定された追加のユースケースにまで拡張する必要がある基盤を CompanYA に提供します。
アーキテクチャフレームワークは、複数の層に分かれています。このフレームワークは、合併および買収シナリオの技術アーキテクチャを理解するための基盤を提供します。すべてのレイヤーが一緒にフローし、完全なエンドツーエンドソリューションを作成します。
高レベル：
ユーザーレイヤー: ユーザー層は、リソースへの接続に使用されるエンドユーザー環境とエンドポイントデバイスを記述します。
- デバイスに関係なく、ユーザーは Workspace アプリからリソースにアクセスできるため、すべてのフォームファクタとデバイスプラットフォームで同一のエクスペリエンスが得られます。
アクセスレイヤー:アクセスレイヤーは、ユーザーがワークスペースとセカンダリリソースに対してどのように認証されるかに関する詳細を記述します。
- ユーザーは、取得前のプライマリ ID で認証を続行します。
- ユーザーは、取得前の多要素認証ソリューションを引き続き使用します。同社が現在、多要素認証を利用していない場合、CompanYA はプッシュベース認証をサポートする電話ベースのTOTPトークンを提供します。
リソース層: リソース層は、定義されたユーザーとグループの特定のSaaS、Web、および仮想リソース、およびリソースに関連付けられたセキュリティポリシーを許可します。
- ユーザーの元の会社に関係なく、ユーザーは、他の会社がホストする承認されたリソースへのシームレスなアクセスを許可する必要があります。
- データをより適切に保護するために、CompanYA では、管理対象リソースからエンドポイントとの間でコンテンツを印刷、ダウンロード、およびコピー/貼り付ける機能を無効にするポリシーが必要です。CompanYa では、アプリケーションのスクリーンスクレイピング、キャプチャ、マルウェアのキーロギングを制限する必要があります。
- エンドポイントのセキュリティ状態は不明であるため、CompanYA では、分離されたブラウザーまたは仮想化されたセッションを使用して、リソースへの VPN レスアクセスを必要とします。
コントロールレイヤー:コントロールレイヤーは、基礎となるソリューションがユーザーの基本的なアクティビティに基づいてどのように調整されるかを定義します。
- ユーザーと企業データを保護するためのポリシーが定められているため、リスクは依然として残っています。CompanYA は、セキュリティ分析サービスを使用して、侵害されたユーザーや内部からの脅威を特定し、安全な環境を維持するためのアクションを自動的に実行します。
- マルチディレクトリ認証を統合するプラットフォームは、外部の脅威や攻撃から保護する必要があります。CompanYA は、統合された Web App Firewall とボット管理を有効にし、認証ポイントを環境内で保護します。
ホスティングレイヤー: ホスティングレイヤーは、オンプレミス、クラウド、ハイブリッドクラウドのいずれであっても、コンポーネントがハードウェアにどのようにデプロイされるかを詳しく説明します。
- Citrix Workspaceでは、オンプレミスのActive Directory ドメインでも、Okta のクラウドベースのサービスであっても、単一のワークスペースサイトを介して、すべての企業のIDプロバイダーにアクセスできる必要があります。
以降のセクションでは、CompanYaの合併および買収戦略のリファレンスアーキテクチャに関する具体的な設計決定について詳しく説明します。
アクセスレイヤー
認証
企業以前の買収で経験した課題の1つは、IDプロバイダの統合方法でした。ID プロバイダーをマージするプロセスには、かなりの時間がかかります。新しい戦略では、CompanYaはCitrixアプリケーションDelivery Controller を使用してすべての認証要求を処理します。
認証プロセスは、アプリケーションDelivery Controller がユーザーの会社を評価し、正しい認証要求を適用します。CompanYA はプライマリ認証のために Okta で標準化されているため、要求は Okta に転送されます。Okta がユーザー認証を完了すると、Okta は認証の成功を識別するトークンを使用してアプリケーションDelivery Controller に応答します。
しかし、CompanYaが買収するすべての企業がOkta を使用しているわけではありません。代わりに、アプリケーションDelivery Controller が企業 B からのユーザーであると識別された場合、ユーザーは Active Directory ユーザー名とパスワードを要求されます。これらの資格情報は、企業 B の Active Directory ドメインに対して検証されます。CompanyB がすでに多要素認証ソリューションを統合している場合、ユーザーは登録済みトークンを引き続き使用します。
強力な認証はセキュリティにとって重要な第一歩であるため、CompanYA では、現在多要素認証を使用していない組織向けのソリューションを用意したいと考えています。この場合、ユーザーが会社の Active Directory ドメインで認証された後、アプリケーションDelivery Controller はネイティブの時間ベースのワンタイムパスワードエンジンを使用して、ユーザーに多要素認証を提供します。ユーザーのデバイスに登録すると、ユーザーはコードを手動で入力するか、プッシュ通知サービスを使用できます。プッシュ通知では、登録済みのモバイルデバイスから「はい」を選択するだけで、多要素認証を実行できます。
nFactor ポリシー
プライマリ認証では、CitrixアプリケーションDelivery Controller が重要な役割を果たします。認証を決定するために、アプリケーションDelivery Controller は nFactor ポリシーを使用します。
認証要求を適切に処理するには、nFactor ポリシーでユーザーが属している会社を知る必要があります。正しい会社 ID が選択されると、nFactor は認証ポリシーの正しいブランチに要求を転送します。
nFactor ポリシーが定義されると、CompanYA は引き続き拡張し、将来的に取得する組織を追加することもできます。nFactor ポリシーにより、CompanYA は LDAP、RADIUS、SAML、クライアント証明書、OAuth OpenID 接続、Kerberos などを含む認証標準を使用して、追加のフローを作成できます。nFactorポリシー・エンジンにより、CompanYAは、再設計なしで追加の買収を継続して統合できる柔軟性を提供します。
ゼロトラストネットワークアクセス
プライベートWebアプリ、仮想アプリ、仮想デスクトップなどの内部リソースへのアクセスを提供するために、CompanyAはSecure Private AccessサービスとCitrix DaaSを使用する予定です。これら 2 つのサービスでは、ゼロトラストネットワークアクセスソリューションを使用します。これは、従来の VPN に代わる安全な方法です。
Secure Private AccessサービスとCitrix DaaSは、クラウドコネクタとコネクタアプライアンスによって確立されたアウトバウンド制御チャネル接続を使用します。これらの接続により、ユーザーは内部リソースにリモートアクセスできます。ただし、これらの接続は
- 定義されたリソースのみがアクセスできるようにスコープが制限されています
- ユーザーのプライマリセキュリティで保護された ID に基づきます。
- ネットワーク通過を許可しない特定のプロトコルのみ
リソースレイヤー
フェデレーション認証サービス
ユーザーは、プライマリIDを使用してCitrix Workspaceに認証します。プライマリ ID は、会社の ID プロバイダーに基づいています。合併および買収に伴う課題の 1 つは、セカンダリ ID に基づくセカンダリリソースへのアクセスです。たとえば、CompanyA は、CompanyB および CompanyC の特定のユーザーが仮想 Windows アプリケーションにアクセスすることを許可します。仮想 Windows アプリケーションにアクセスするには、仮想リソースを含むドメイン内にユーザーアカウント (セカンダリ ID) が必要です。CompanyB ユーザーのアカウント (プライマリ ID) は、CompanYA リソース (セカンダリ ID) に対して認証されません。CompanYAは、プライマリとセカンダリIDの間で資格情報を変換し、仮想Windowsアプリケーションにシングルサインオンを提供するために、Citrix Cloud内のフェデレーション認証サービスを使用します。
Workspace Single Sign-On の技術概要には 、フェデレーション認証サービスに関連する追加情報が含まれています。
リソースセキュリティポリシー
CompanYA は、内部者の脅威によるデータ損失のリスクを制限したいと考えています。さまざまなアプリケーションタイプ内で、CompanYA には、ユーザーがデータをコピー、ダウンロード、または印刷できないように多数の制限が組み込まれています。
CompanYA は、ベースラインポリシーとして、次のことを定義しました（ユーザーとアプリケーションに基づいて、必要に応じてポリシーを緩和できます）。
| カテゴリ | SaaS アプリ | Web アプリ | 仮想アプリ/デスクトップ |
|---|---|---|---|
| クリップボードへのアクセス | 拒否済み | 拒否済み | クライアントからサーバへのみ |
| 印刷 | 拒否済み | 拒否済み | 拒否済み |
| ナビゲーション | 拒否済み | 拒否済み | 該当なし |
| ダウンロード | 拒否済み | 拒否済み | 拒否済み |
| 透かし | 有効 | 有効 | 有効 |
| キーロギングの防止 | 有効 | 有効 | 有効 |
| スクリーンショット防止 | 有効 | 有効 | 有効 |
アプリ保護ポリシー技術概要には 、キーロギングとスクリーンショット防止ポリシーに関する追加情報が含まれています。
制御レイヤー
Web App Firewall
ユーザーがCitrix Workspaceに認証すると、合併および買収戦略をサポートするカスタム認証フォームにアクセスします。Citrix Application Delivery Controllerでホストされる認証フォームは、ボットや攻撃から保護する必要があるパブリックWebページです。パブリックWebアプリケーションの保護を強化するために、CompanYaはCitrixアプリケーションDelivery Controller ソリューションのボット管理コンポーネントとWeb App Firewallコンポーネントを使用します。
防御の最初のラインはボット管理です。ボットは、不正な要求でサービスを圧倒することで、パブリックウェブアプリを簡単にクラッシュまたは遅らせることができます。アプリケーションDelivery Controller ボット管理コンポーネントは、ボットリクエストを検出し、システムが無効にならないようにすることができます。
2 番目の防御線は Web App Firewall です。Web App Firewall では、送信された資格情報を処理するポリシーエンジンが攻撃から保護されます。これらのタイプの攻撃は、通常、バッファオーバーフロー、SQL インジェクション、クロスサイトスクリプティングです。Web App Firewall は、これらの攻撃による認証ポリシーエンジンへの影響を検出して拒否します。
セキュリティ分析
CompanYA は、影響が大きすぎる前に、環境に対する内部的な脅威を特定して阻止する必要があります。
環境を保護するために、CompanYaはCitrix Security Analyticsを使用して、内部者の脅威、侵害されたユーザー、および侵害されたエンドポイントを特定します。多くの場合、脅威の 1 つのインスタンスで抜本的なアクションを保証するものではありませんが、一連の脅威はセキュリティ侵害を示す可能性があります。
CompanYA は、次の初期セキュリティポリシーを開発しました。
| 名前 | 条件 | アクション | 理由 |
|---|---|---|---|
| 異常なアクセス | 疑わしいIPからログオンし、異常な場所からのアクセス | ユーザーのロック | ユーザーが異常な場所や疑わしいIPからログインした場合、そのユーザーが侵害されたことを示す強い兆候があります。 |
| 異常なアプリの動作 | 異常な場所からのアプリの使用とアクセスの異常な時間 | セッションの録画を開始 | ユーザーが奇妙な時間と場所で仮想アプリにアクセスすると、ユーザーが危険にさらされる可能性があります。セキュリティ分析は、管理者が正当性を検証するためにセッションを記録します。 |
| クレデンシャルエクスプロイトの可能性 | 過剰な認証失敗と異常な場所からのアクセス | ウォッチリストに追加 | ユーザーが異常な場所から多くの認証に失敗した場合、誰かがシステムに侵入しようとしていることを示している可能性があります。しかし、攻撃者はまだ成功していません。ウォッチリストにユーザーを追加する必要があるだけです。 |
Citrixユーザーリスク指標ドキュメントには、Citrix Security Analyticsに提供されるさまざまなリスク指標に関する追加情報が含まれています。
［Citrix ポリシーとアクション ］ページには、Citrix Security Analyticsが実行できる修復手順に関する情報が含まれています。
ソース
合併と買収戦略の計画を容易にするために、 適応可能なソース図を提供したいと考えています 。