どんなクラウドエンジニアにどれだけのアプリケーションが彼らの環境で実行されているかを尋ねると、あなたはボールパーク番号を取得します。5分後に再度尋ねると、彼らはそれを倍増するかもしれません。
信じ難いが、CI/CDパイプラインの再展開、ゾンビのワークロード、インフラストラクチャの曖昧な隅にある伝統的なアプリケーション、そして数えきれないアイデンティティプロバイダー(IdPs)の間では、トラックを失うのは簡単だ。
何が起きているかを知らないと、それを管理したり、セキュリティを確保したりすることはできません。
統合から展開まで、他のすべてが継続的に進むにつれて、発見もそうであるべきだ。
断片化の問題
今日の典型的な企業では、アプリケーションはAWS、Azure、GCP、およびたぶんプライベートクラウドまたは2で展開されています。
たとえば、Google Cloud Platform (GCP) を使用すると、アプリケーションをさまざまな方法で展開できます。App Engine、Cloud Run、Compute Engine、Google Kubernetes Engine、Apigee Gateway を含むオプションがあります。Azure およびAmazon Web Services などの他のクラウドプラットフォームには、アプリケーションワークロードのための多くの展開オプションがあります。一部は、Kubernetes サポートなどの類似性がありますが、そのクラウドプラットフォームにユニークな他のテクノロジーがあります。
中心的な発見メカニズムがなければ、これらのアプリのいくつかは容易に裂け落ちることができます。Infrastructure-as-code (IaC) も、Terraform のように、特に開発者が手動のデプロイのためにテンプレートを回避したり、タグを更新するのを忘れたときには、常に全体像をキャプチャすることはできません。
もちろん、これらのアプリケーション環境へのアクセスを制御するアイデンティティシステムにも同様の拡張があります. Enterprises can have a mix of Okta, Microsoft Entra ID, and Amazon Cognito, as well as on-premises Active Directory or legacy web access management products, legacy SiteMinder instances, and on-prem Active Directory, often coexisting. 企業は、オンプレミスアクティブディレクトリや古いウェブアクセスの管理製品、古いSiteMinderインスタンス、およびオンプレミスアクティブディレクトリを組み合わせることができます。
断片的なアイデンティティ
アプリケーションは、いつ、どこで展開されたかによって異なる IdP に対して認証する場合があります. たとえば、チームは内部アプリケーションのための Okta を選択する場合がありますが、顧客向けのシステムは Microsoft に依存します。
その結果、認証、ポリシー、アクセスパターンが広がり、一貫して監査することはほぼ不可能です。
このレベルの
なぜ伝統的な監査はそれを削減しないのか
監査モデルの一例は、ビッグ4コンサルティングを導入し、監査を実行し、レポートを生成し、それを1日呼び出すことです。
CI/CD パイプラインは、削除されたアプリを再配布する可能性があります。開発チームはセキュリティを通知することなく新しいものを作成する可能性があります。あるいは、リラックスした SiteMinder ポリシーを備えた眠っているアプリは、まだ @company.com メールを持った誰でも入力できる可能性があります。
さらに懸念されるのは、これらの監査は本質的に範囲が狭いものであり、絶え間なく変化しているシステムの瞬間写真をキャプチャしています。どんな有意義な発見も、監査プロセスに関わる人々にシロイドされ、しばしば次のラウンドまで誰も再度見ない静止文書に保存されます。
継続性はなく、自動化もなく、データが収集された日を超えて正確であるという保証もありません。
ドルとセキュリティ感
コストを忘れてはいけません。これらの評価はしばしば数週間の努力と数十万ドルを要します。その結果は、グラフとボールポイントがボードルームで素晴らしいように見える、かっこいいプレゼンテーションです。しかし、忘れられたGCPクラスターで実行されているコンテナ化されたアプリケーションへのアクセスをIdPがどのように管理しているかを追跡しようとしているエンジニアにどのような価値をもたらしますか?
一方、攻撃者は次の監査サイクルを待っているわけではありません。彼らは攻撃の表面をスキャンし、あなたのスプレッドシートが捕らえなかったエンドポイントを探しています。
絶え間ない発見ってどんな感じ?
多くのセキュリティチームは、アプリケーションの可視性を備えて盲目的にウォークアムールをプレイすることに閉じ込められています。彼らは1つの影のアプリケーションを発見し、さらに3つが裂け穴に隠れていることを発見します。問題は怠慢さやツールの欠如によるものではなく、環境が絶えず変化していることです。開発チーム間で新しいサービスが回転し、CI/CDパイプラインが古いサービスを再配備し、インフラストラクチャが一週間で進化し、静的インベントリを維持することは不可能です。
そのため、絶え間ない発見のスケールが発生します。それは、あなたが四半期に一度行うものから、あなたの操作の構造に構築するものに視界を変えます。
**Cloud-native scanning:**Call to APIs across cloud platforms (GCP, Azure, AWS) to list deployments across services: App Engine, ECS, Lambda, Cloud Run, etc. (クラウドネイティブスキャン)
Identity correlation: 各アプリケーションを IdP にマッピングし、MFA 執行およびカタログ認証パターン(SAML、OIDC、LDAP、ヘッダーベースなど)を確認します。
CI/CD monitoring: パイプラインがメモを受け取らなかったため、削除された後に再び表示されるアプリをキャッチします。
Tagging and classification: メタデータを適用して、コンプライアンス範囲(PCI アプリケーションなど)、部門、またはデータの敏感性によって組織します。
継続的な発見は、あなたのインフラストラクチャとあなたのアイデンティティアーキテクチャの間の結合構造を提供します。
リアルタイムのセキュリティ姿勢管理、プロアクティブなコンプライアンス、および効率的なインシデント対応のためのステージを設定します。
定期的な火災演習の代わりに、継続的な発見は、アプリケーションの可視性をライブプロセスとして扱います。
リアル・ワールド・ユーザ・ケース:The 2,500 vs. 4,500 app guess
あるフォーチュン500社では、新しく任命されたCTOに「あなたの環境にはどれだけのアプリケーションがありますか?」という単純な質問を受けました。
「2,500」彼女は自信を持って答えたが、「待って、同じサイズの別の会社を買ったばかりだ。
その答えは記録のシステムから来なかった。それは、買収ヘッドカウントと平等性の粗大な仮定に基づく推測だった。 合計を確認するアプリケーションインベントリはなく、ダッシュボードはなく、ただのカバーバック数学だった。そしてこれはジュニアITアナリストではなかった。
このようなシナリオは、信頼性の高い、継続的に更新されているアプリケーションレジストリの欠如を強調しているため、メモリ、マニュアル、部族の知識に依存することを余儀なくされます - すべてダイナミックでクラウドベースの環境では失敗します。
管理チームがプレイ中のアプリの数を定量化できない場合、どのようにしてこれらのアプリが安全で、コンプライアンスに適合し、適切に管理されていることを確実にすることができるのでしょうか。
なぜエンジニアやIAMチームが関心を持たなければならないのか?
追跡されていないアプリケーションは、攻撃者にとって低いフルーツです。IAMを管理している場合、アプリケーションがMFAなしで基本的な認証を使用している場合は、アプリケーションについて知っていたかどうかはあなた次第です。そして、コンプライアンスを維持する責任がある場合、6ヶ月のスケジュールは、監査官が現在のアクセスと認証の詳細を要求するときにあなたを保護しません。
- You know what's out there
- 誰がアクセスできるかわかる
- 安全かどうかわかるか
そして、あなたはそれを証明することができます。
変化の世界と向き合う方法
Discovery はリストを作成することをはるかに超えており、隠されたリスクを表面化する上で重要な役割を果たします。
古いアプリケーション、誤って構成されたサービス、または許可されていない展開が依然として静かに、気付かず実行されている可能性のあるクラウドプロパティの暗い隅々です。
無視されたシステムは、攻撃ベクター、コンプライアンス責任、または予期せぬコストの源となり、セキュリティおよびアイデンティティーチームにアプリケーションの状況のリアルタイムマップを提供し、問題がエスカレートする前に決定的な行動を取ることができます。
(前述したように、ゲリー・ゲベルは、アイデンティティ・マネジメントとセキュリティの分野で活動する会社と専門的に関わっています。
