询问任何云工程师在他们的环境中运行了多少应用程序,你会得到一个球场号码,五分钟后再次询问,他们可能会翻一番,不是因为他们在逃避,而是因为他们不知道确切的数字。
很难相信,但在CI / CD管道重新部署,僵尸工作负载,基础设施的模糊角落的遗传应用程序和太多身份提供商(IdPs)之间,很容易失去追踪。
当你不知道正在运行的东西时,你无法管理和保护它。
随着其他一切变得连续 - 从整合到部署 - 发现也应该如此。
分裂问题
在今天的典型企业中,应用程序部署在 AWS、Azure、GCP 和可能是一个私有云或两个。
使用 Google Cloud Platform (GCP) 作为一个例子,可以以多种方式部署应用程序. 您有包括 App Engine、Cloud Run、Compute Engine、Google Kubernetes Engine 和 Apigee Gateway 等选项。 其他云平台如 Azure 和 Amazon Web Services 同样有许多应用程序工作负载的部署选项。
即使是基础设施代码(IaC),像Terraform,并不总是捕捉整个图像,特别是当开发人员绕过模板进行手动部署或忘记更新标签时。
当然,对控制访问这些应用程序环境的身份系统也有类似的扩展性。企业可以拥有Okta、Microsoft Entra ID和Amazon Cognito的组合,以及本地的Active Directory或遗留的Web访问管理产品,遗留的SiteMinder实例和本地的Active Directory,通常共存。
破碎的身份
例如,一个团队可能会为内部应用选择 Okta,而面向客户的系统则依赖于 Microsoft。
结果是广泛的凭证、政策和访问模式,使得几乎不可能连续进行审计,即使知道MFA是否为特定应用程序启用,也成为了一个研究项目。
这种水平的
为什么传统审计不削减它
一个审计模型示例包括引入四大咨询公司,执行审计,生成报告,并将其称为一天。
CI/CD 管道可能会重新部署已停用的应用程序. 开发团队可能会在不通知安全的情况下创建新东西。 或者更糟糕的是,具有松散的 SiteMinder 策略的安静应用程序仍然可以让任何拥有 @company.com 电子邮件的人直接进入。
更令人担忧的是,这些审计的范围本质上是狭窄的,它们捕捉了不断变化的系统的时刻图像,任何有意义的发现都被用于参与审计过程的人,并且通常存储在静态文件中,直到下一轮才有人重新审查。
没有连续性,没有自动化,也没有保证数据在收集之日之后仍然准确。
美元和安全感
不要忘记成本. 这些评估通常需要数周的努力和数十万美元的努力。 结果是一个漂亮的演示文稿,图表和子弹点在董事会室看起来很棒。
与此同时,攻击者并不等待你的下一个审计周期,他们正在扫描你的攻击表面,寻找你的电子表格没有捕获的终点,这就是为什么今天转向连续发现是必不可少的。
不断的发现是什么样子?
许多安全团队都被困在使用应用程序的可见性中。他们只发现一个阴影应用程序,以便在裂缝中找到另外三个隐藏的应用程序。问题不是由于懒惰或缺乏工具,而是环境不断变化。
这就是为什么不断的发现规模。它将可见性从你每季度做一次的东西转移到你构建的业务结构中的一些东西。
**云原生扫描:**通过云平台(GCP、Azure、AWS)调用API,列出服务中的部署:App Engine、ECS、Lambda、Cloud Run等。
Identity correlation: 将每个应用程序绘制到其IDP,验证MFA执行和目录身份验证模式(SAML,OIDC,LDAP,基于头部等)。
CI/CD monitoring: 捕获在关闭后重现的应用程序,因为管道没有收到备忘录。
Tagging and classification应用元数据以合规范围(如 PCI 应用程序),部门或数据敏感性来组织。
持续的发现为您的基础设施和身份架构提供连接。
它为实时安全姿势管理、主动遵守和高效的事件响应奠定了舞台,如果没有它,下一个与应用程序相关的破坏可能不会来自复杂的利用,而是你的团队甚至不知道正在运行的东西。
而不是定期的消防演习,持续的发现将应用程序的可见性视为一个活跃的过程。
现实世界的使用案例:2500 vs.4500应用程序猜测
在一家名为Fortune 500的公司,一位新任命的CTO被问到一个看似简单的问题:“你的环境中有多少个应用程序?”
“2,500,”她自信地回答,然后停下来,“等一下,我们刚刚收购了一家大约相同规模的公司,让我们叫它4500。
这个答案不是来自一个记录系统的。 这是一个猜测,基于收购总数和粗略的平等假设. 没有应用库存来咨询,没有仪表板来确认总数 - 只是背后包数学。
类似的场景很重要,因为它们强调缺乏可靠的,不断更新的应用程序注册表,没有一个,公司被迫依赖于内存,手动表格和部落知识 - 所有这些在动态的基于云的环境中失败。
它还揭示了不确定性的运营和安全风险,如果领导团队无法量化游戏中的应用程序的数量,那么如何确保这些应用程序是安全的,合规的,并得到适当的管理?
为什么工程师和IAM团队应该关注?
未跟踪的应用程序对于攻击者来说是低悬挂的果实。如果您正在管理IAM,而应用程序仍在使用没有MFA的基本身份验证,那就取决于您,无论您是否了解该应用程序。
- 你知道外面是什么
- 你知道谁有访问权
- 你知道它是否安全
你可以证明它。
如何跟上一个变化的世界
发现远远超出了编制列表,它在揭露隐藏的风险方面发挥着至关重要的作用。
您云端的黑暗角落,传统应用程序、错误配置的服务或未经授权的部署可能仍在安静且未被注意的情况下运行。
被忽视的系统可以成为攻击引擎、合规责任或意外成本的来源,持续的发现关闭了循环,为安全和身份团队提供了应用环境的实时地图 - 运行了什么,如何保护它,以及谁可以访问 - 以便他们在问题升级之前采取决定性行动。
(如前所述,格里·盖贝尔(Gerry Gebel)是一家在身份管理和安全领域运营的公司,他的观点反映了他在行业中的专业知识和经验。
