アクセス戦略を再考し、BeyondCorp を検討しましょう

数年前、Forrester は古いセキュリティのマントラである「信頼しつつも検証も」は死んだと宣言し、「ゼロ トラスト」という用語を作り出した。 その議論は、最初の認証成功に基づいてすべてを信頼したが、その後は実際には検証されなかったというものでした。 いつものように、このような流行語は、大きな興奮から始まり、すぐに大きな行動を起こさないという誇大宣伝サイクルを経ることが多い。 ゼロ トラストとその派生概念 (アプリケーションが新しい境界であるなど) は、現在、現実世界のアーキテクチャと実装で普及しつつあります。 このセキュリティ戦略の強力な支持者である Google は、その実装において大きな進歩を遂げており、その実装プロセスを公開するほど親切です。 彼らはそれを「BeyondCorp」と名付けました。

Google は最近、このトピックに関する 4 番目の研究論文を宣伝するブログ記事を公開しました。この論文では、移行の長いプロセスを経てどのように生産性を維持したかが説明されています。 BeyondCorp アーキテクチャを要約すると、オンプレミス アクセスとリモート アクセスの区別はなくなり、単なるアクセスになります。 すべての認証およびアクセス要求は、ユーザーの場所やデバイスに関係なく、集中アクセス ゲートウェイを通過する同じパスをたどります。 ただし、認証の課題とアクセスの決定は、さまざまなリスク要因に基づいて異なる場合があります。 ゲートウェイは認証プロンプトを提供しますが、リスク プロファイルに基づいたきめ細かい属性ベースのアクセス制御も可能にします。 これにより、ユーザーに一貫性とシンプルさが提供され、攻撃が成功する可能性を減らすのに非常に役立ちます (過去の記事で説明したように)。

たとえば、ユーザーが、公開されている可能性のある会社の発表のみを含む会社の Web アプリに接続しようとしており (リスクが低い)、オフィスのデスクまたは会社から支給されたラップトップから接続しようとしている場合 (リスクが低い)、セキュリティ管理者として、アクセスにはユーザー名とパスワードのみを要求することを選択する場合があります。 しかし、ユーザーが金融関連のアプリケーション (高リスク) に、ロシアのどこか (高リスク) から、不明なデバイス (高リスク) から接続しようとしているとします。 セキュリティ管理者である私は、アクセス ゲートウェイに、これはリスクが高すぎると判断してアクセスを拒否するポリシーを設定したり、少なくともユーザーに ID 確認のための 2 番目または 3 番目の要素の入力を求めたりすることがあります。 さらに、きめ細かな属性ベースのアクセス制御により、リスク レベルに一致するアクセス要求に、縮小された形式のアクセス (読み取り/書き込みではなく読み取り専用など) を付与することもできます。

あなたにとって、これらのいずれかが馴染み深いものになりますか? F5 パートナーの Microsoft Azure AD、 Ping 、 Oktaなどの IDaaS サービスを使用している場合は、すでにある程度これを実行していることになります。 BeyondCorp モデルを構成するコンポーネントは他にもありますが、アクセス ゲートウェイは間違いなくアーキテクチャ全体の核心です。 Google は現在、他社が使用できるように「アイデンティティ認識プロキシ」（IAP）を提供していますが、制限がないわけではありません。 これを Google Compute Platform (GCP) 上のアプリでのみ使用できることに加え、一部の顧客は、アクセス制御の細分性と柔軟性に関する課題を指摘し、セッションの長さを構成できること、GCP ごとではなくアプリケーション ポリシーごと、柔軟なステップアップ 2 要素認証を実行する機能を求めていました。

偶然ではありませんが、F5 はこれらの機能などを提供するアクセス ソリューションを提供しています。 また、GCP 内に存在するアプリだけでなく、すべての環境で機能します。 完全にクラウドでもハイブリッドでも、F5 はあらゆるアーキテクチャに適合する安全で集中化されたスケーラブルなアクセス ソリューションを提供します。 詳細については、 f5.com/apmをご覧ください。