azure 安全组_具有安全性和设计注意事项的Azure成本跟踪

azure 安全组

Azure costs can quickly mount, without careful supervision and management. This article will detail cost mitigation strategies using security and design

无需仔细的监督和管理，Azure成本即可Swift增加。 本文将详细介绍使用安全性和设计的成本降低策略

The cloud offers a wide range of tools at a fraction of the cost that we would need, if we managed it fully ourselves. However, we still may run into some scenarios where monitoring our Azure costs will be key to identify a possible attack, identify possible optimization, or provide incentives to our organization to improve how we’re designing our applications. Before we look at techniques to audit our use of resources, we should consider our design with how we use Azure across our organization. Good design can save us hours in development when we begin to monitor our costs.

如果我们完全自行管理，云将以所需成本的一小部分提供各种工具。 但是，我们仍然可能会遇到某些情况，在这些情况下，监视Azure成本将是确定可能的攻击，确定可能的优化或为组织提供激励以改善我们设计应用程序的方式的关键。 在研究审核资源使用的技术之前，我们应该考虑我们的设计以及在整个组织中如何使用Azure。 好的设计可以在我们开始监控成本时为我们节省开发时间。

审核Azure成本的设计注意事项 (Design Considerations for Auditing Azure Costs)

With the exception of start-up situations where we use few resources in Azure, how we design our applications or use specific tools in the cloud with on premise applications will affect how we want to audit our costs. For an example, we could simply look at our total spend for a month in our subscription – if we maintain one subscription only like the below image shows.

除了在Azure中使用很少资源的启动情况以外，我们如何设计应用程序或在内部使用应用程序的云中使用特定工具的方式都会影响我们想要审核成本的方式。 例如，如果我们仅维护一个订阅（如下图所示），我们可以简单地查看订阅中一个月的总支出。

But this figure may mean very little if we manage many teams that use many resources across many different environments – such as a development environment, a preproduction environment, and a production environment. In the same situation, only seeing the spend in a specific environment may mean less than seeing the spending by team – if we manage an environment with multiple teams.

但是，如果我们管理许多团队，这些团队在许多不同的环境中使用许多资源，例如开发环境，预生产环境和生产环境，那么这个数字可能意义不大。 在相同情况下，如果我们管理一个由多个团队组成的环境，那么仅查看特定环境中的支出可能比按团队查看支出要少。

Outside of the rare exceptions where we use very few cloud resources and can simply look at the total costs; we want to consider how we use Azure. The below questions make strong starting points so that we know how to audit our usage.

除了极少数的例外，我们只使用很少的云资源，并且可以简单地查看总成本； 我们想考虑如何使用Azure。 以下问题是一个很好的起点，因此我们知道如何审核使用情况。

1. Are we using Azure with premise-based resources for our applications? We have to be careful about how meaningful any Azure costs audit may be here because it’s possible that issues with our premise-based resources cause a spike in Azure use, so any auditing in Azure should be complemented with auditing for premise-based resources
   我们是否将Azure与基于前提的资源一起用于我们的应用程序？ 我们必须谨慎考虑任何Azure成本审核在这里的意义，因为我们的基于前提的资源可能会导致Azure使用量激增，因此Azure的任何审核都应与基于前提的资源审核相辅相成
2. How are our applications managed on the human capital level? Do we have teams that create and maintain the applications that run in Azure? Do we run multiple applications or can we divide our application into meaningful partitions for auditing spending?
   如何在人力资本层面管理我们的应用程序？ 我们是否有创建和维护在Azure中运行的应用程序的团队？ 我们是运行多个应用程序还是可以将应用程序划分为有意义的分区以审核支出？
3. How do we manage multiple environments in Azure? I’ve seen and discussed designs where all applications and their necessary cloud infrastructure are run under one grouping (subscription, resource group, etc) for all environments such as development, preproduction and production, and I’ve seen these environments partitioned to different groupings. Due to possible resource limitations, the latter may be more useful for auditing Azure cost information along with horizontally scaling better
   我们如何在Azure中管理多个环境？ 我已经看到并讨论了针对所有环境（例如开发，预生产和生产）将所有应用程序及其必需的云基础架构按一个组（订阅，资源组等）运行的设计，并且我已经看到这些环境分为不同的组。 由于可能的资源限制，后者可能对审核Azure成本信息以及更好地横向扩展更有用。
4. Other than management, who is the primary consumer of this information? Will we share this information with teams and use it as incentives (ie: bonuses for improving performance)?
   除管理层外，谁是此信息的主要使用者？ 我们是否会与团队共享此信息并将其用作激励措施（即：提高绩效的奖金）？

With these initial questions, we can design our infrastructure in Azure (or update existing infrastructure) to provide what information we need based on our answers. The two big areas of concern with costs involve security and organization – whether team organization or environment organization.

有了这些最初的问题，我们可以在Azure中设计基础结构（或更新现有基础结构），以根据我们的答案提供所需的信息。 涉及成本的两个主要方面涉及安全和组织-团队组织还是环境组织。

安全和Azure成本 (Security and Azure Costs)

While the cloud may provide some security features, there are risks associated with using any cloud provider. One of the risks may involve a compromise to the administrator or other account with enough permissions to increase the scale of resources above what’s needed – imagine a SQL database being scaled to the highest level when the basic level is needed. This compromise may impact a person or organization’s costs. Unlike a denial of service attack on a site – where a site is offline for customers, this attack keeps the resources online by overuses resources, costing the company or individual money.

尽管云可能提供某些安全功能，但是使用任何云提供商都会有风险。 其中的风险之一可能是对管理员或具有足够权限的帐户的妥协，以使资源规模超出所需的范围–假设需要基本级别时，将SQL数据库扩展到最高级别。 这种妥协可能会影响个人或组织的成本。 与站点上的拒绝服务攻击不同（站点使客户离线），该攻击通过过度使用资源使资源保持在线状态，从而使公司或个人蒙受损失。

With the rise of sim-swaps and other two-factor authentication attacks (hackers using standard two-factor authentication against users), we should be careful how we allow ourselves to be validated. In general, some best practices I recommend to avoid these situations for individuals:

随着sim-swaps和其他两因素身份验证攻击（黑客使用针对用户的标准两因素身份验证）的兴起，我们应该小心如何允许自己进行验证。 通常，我建议一些最佳做法来避免个人遇到这些情况：

• DHS Study on Mobile Device Security I highly recommend reading DHS移动设备安全研究》的报告，我强烈建议阅读
• In general, email is superior for two-factor authentication provided that your mobile is not tied directly to your email and your email doesn’t use a standard naming convention
  通常，如果您的手机不直接与电子邮件绑定并且电子邮件不使用标准命名约定，则电子邮件对于两因素身份验证而言比较优越。

Unfortunately, organizations tend to violate these security practices, such as using email names that allow for easy spear-phishing attacks, etc. If login credentials are compromised and changed, even the best audit for Azure costs may not be effective because an attacker can reset this. This is an important point worth considering for design – we want multiple receivers of our audit information and any silence on spending could be a sign of an attack. Still, in the case of security, prevention is much cheaper than cure.

不幸的是，组织倾向于违反这些安全做法，例如使用允许轻易进行鱼叉式网络钓鱼攻击的电子邮件名称等。如果登录凭据被泄露和更改，则即使对Azure成本的最佳审核也可能无效，因为攻击者可以重置这个。 这是在设计时值得考虑的重要点-我们希望多个审计信息的接收者，而任何对支出的沉默都可能是攻击的迹象。 不过，就安全而言，预防要比治疗便宜得多。

Attackers can compromise Azure in other ways, by introducing malicious code, but for the context of this article, we are keeping these attacks on the context of overspending on resources. One login may be enough to reset any Azure cost auditing we have, but if this audit is disabled (or doesn’t follow a pattern we expect), we may detect the problem quickly. Likewise, if our users don’t have too many permissions, even if compromised, the attacker may not be able to scale or scale without triggering alerts by monitoring users.

攻击者可以通过引入恶意代码，以其他方式破坏Azure，但是对于本文而言，我们将这些攻击保留在资源超支的情况下。 一次登录可能足以重置我们拥有的任何Azure成本审核，但是如果禁用了此审核（或未遵循我们期望的模式），我们可能会Swift发现问题。 同样，如果我们的用户没有太多权限，即使受到损害，攻击者也可能无法通过监视用户触发警报而无法扩展或扩展。

组织和Azure成本 (Organization and Azure Costs)

When we consider our organization and how our organization uses Azure, this will directly affect how we want to audit for our Azure costs. With the organization component, we want to look at how Azure is used across teams, how we’ve partitioned our environments, and how we want our environments to be grouped. Consider the below two images that contrast a horizontally partitioned environment – one by demarcating environments on the subscription level and the other by demarcating environments on the resource group level. For tracking our costs, we want to think about designs that allows us to provide our organizational structure the most meaningful information possible.

当我们考虑组织以及组织如何使用Azure时，这将直接影响我们要审计Azure成本的方式。 借助组织组件，我们希望了解如何在各个团队之间使用Azure，如何对环境进行分区以及如何对环境进行分组。 请考虑以下两个与水平分区环境形成对比的图像：一个是在订阅级别划分环境，另一个是在资源组级别划分环境。 为了跟踪我们的成本，我们需要考虑允许我们向组织结构提供尽可能有意义的信息的设计。

The team part of the organization is the easiest because most companies with multiple teams either have shared development of any resource or partitioned develop, where a specific team develops specific resources. The information we get about auditing can be shared on the team level or management level and we may face more challenges in the shared environment where improvements must get consensus across multiple developers. For the actual auditing, we may require that individual teams manage auditing their own resources along with organizing this (such as using tags in Azure).

组织的团队部分是最容易的，因为拥有多个团队的大多数公司要么共享任何资源的开发，要么共享开发的资源，而由特定的团队开发特定的资源。 我们获得的有关审核的信息可以在团队级别或管理级别共享，并且在共享环境中我们可能面临更多挑战，在共享环境中，改进必须在多个开发人员之间达成共识。 对于实际的审核，我们可能要求各个团队管理审核自己的资源并进行组织（例如在Azure中使用标签）。

When we consider environment partitions and auditing Azure costs, we have to think about the purpose of our environments. The development, preproduction, production approach is very common (some companies have 3-9 different environments). Likewise, a growing approach is using development, functional testing only, security testing only, performance testing only, beta customers, and production. This differs because we may not care as much about scale for functional or security testing, whereas we may scale our performance environment higher prior to a test and lower the scale following a test. In a similar manner, we would probably expect our costs for our beta customers to be much lower than our main group of customers, provided the beta customers are a small fraction of the entire customers.

在考虑环境分区和审核Azure成本时，我们必须考虑环境的目的。 开发，预生产，生产方法非常普遍（一些公司具有3-9个不同的环境）。 同样，越来越多的方法是使用开发，仅功能测试，仅安全测试，仅性能测试，beta客户和生产。 这是不同的，因为我们可能不太在乎功能或安全性测试的规模，而我们可能会在测试之前将性能环境扩展到更高的水平，而在测试后降低性能环境。 以类似的方式，如果Beta客户只占整个客户的一小部分，我们可能期望我们的beta客户的成本比我们的主要客户群体低得多。

How we group environments matters because we may want these in their own subscriptions, resource groups, or partitioned in another organized manner, depending on what resources we’re using. Consider the below example image where we have three Azure SQL databases for different environments sharing the same server. If we think about this in the context of monitoring Azure costs, is this design the most appropriate? What if we need to add new databases in the future? The answer depends because we may only need to use one Azure SQL databases, or these may be part of a larger group of resources we need to use.

对环境进行分组的方式很重要，因为我们可能希望将它们放在自己的订阅，资源组中，或者以其他有组织的方式进行分区，具体取决于我们正在使用的资源。 考虑下面的示例图像，其中我们有三个Azure SQL数据库，用于不同环境共享同一服务器。 如果我们在监视Azure成本的情况下考虑此问题，那么此设计是否最合适？ 如果将来需要添加新的数据库怎么办？ 答案取决于，因为我们可能只需要使用一个Azure SQL数据库，或者它们可能是我们需要使用的更大资源组的一部分。

结论 (Conclusion)

To save ourselves the most time when considering the automation of auditing Azure costs, we want to review our design – from how we access Azure resources for security purposes to how our organization uses Azure. The automation step and monitoring becomes easy when we have a design that is consistent for how we use Azure, along with preventing attackers from disabling it if they try to compromise our login.

为了在考虑自动化审核Azure成本时节省最多的时间，我们希望查看我们的设计-从出于安全目的访问Azure资源的方式到组织使用Azure的方式。 如果我们的设计与我们使用Azure的方式一致，那么自动化步骤和监视将变得很容易，并且可以防止攻击者在尝试破坏我们的登录名时禁用它。

目录 (Table of contents)

Azure Costs Tracking with Security and Design Considerations

Controlling Azure Costs Using Scaling and Tags

User Security and Risks to Azure Costs

Extract Azure Costs Using PowerShell

Tracking Azure Costs with Cost Management

Handling Unused and Unnecessary Resources Impacting Azure Costs

Finding Unused Resources Impacting Azure Costs

Situations When We May Want Higher Azure Costs

具有安全性和设计注意事项的Azure成本跟踪

使用扩展和标签控制Azure成本

用户安全和Azure成本风险

使用PowerShell提取Azure成本

通过成本管理跟踪Azure成本

处理影响Azure成本的未使用和不必要的资源

查找影响Azure成本的未使用资源

我们可能需要更高的Azure成本的情况

翻译自: https://www.sqlshack.com/azure-costs-tracking-with-security-and-design-considerations/

azure 安全组