azure 安全组
We’ve looked at both the organization and development side of managing Azure costs. One risk we have is attackers who compromise an account and mis-scale resources (such as scaling up), driving up our costs. Another scenario is attackers scaling resources too low that affects client’s ability to do their work (performance problems) – a separate risk that may result in lower costs on the cloud side, but higher costs against our reputation. A third risk is reconnaissance of our Azure use: this allows the attackers to get information about our design and later make a wide range of attacks that will appear as normal to us – in this case, Azure costs may be only one of the impacts with other impacts being as severe.
我们已经在管理Azure成本的组织和开发方面进行了研究。 我们面临的风险之一是攻击者破坏了帐户并滥用了资源（例如扩大规模），从而增加了我们的成本。 另一种情况是，攻击者将资源扩展到过低的水平，从而影响了客户的工作能力（性能问题），这是一种单独的风险，可能导致云端成本降低，但损害我们声誉的成本更高。 第三个风险是对我们使用Azure的侦察：攻击者可以获取有关我们设计的信息，然后再进行对我们来说很正常的一系列攻击-在这种情况下，Azure成本可能只是影响其他影响同样严重。
With the cloud, we still must follow strict security principles to reduce the risk of these types of attacks. We’ll look at following security principles that combine least permissions along with appropriate auditing that will help us prevent and detect compromises that may add to our costs.
对于云，我们仍然必须遵循严格的安全性原则，以减少此类攻击的风险。 我们将研究以下安全原则，这些原则将最少的权限与适当的审核结合在一起，这将有助于我们预防和发现可能增加成本的危害。
最小权限 (Least Permissions)
To reduce the likelihood that one account is compromised and any auditing for Azure costs is disabled, accounts with access to our Azure assets should follow the least permissions principal. If a user only needs read for validation purposes, we should not grant a role that could possibly compromise our design – such as an attacker compromising an account and increasing the scale of our resources. In the below image, we see an addition of a Reader role called DBDevs (database developers) for our development database. In this example, the account that would create changes would have higher permissions, but would be an automated user, while the database development team would have read access for validation and would build in a local environment.
为了减少一个帐户被盗用并且禁用任何Azure成本审核的可能性，有权访问我们的Azure资产的帐户应遵循最小权限主体。 如果用户仅需要阅读以进行验证，则我们不应授予可能损害我们设计的角色，例如攻击者破坏帐户并增加我们的资源规模。 在下图中，我们为开发数据库添加了一个称为DBDevs（数据库开发人员）的Reader角色。 在此示例中，将创建更改的帐户将具有更高的权限，但将是一个自动用户，而数据库开发团队将具有读取访问权限以进行验证，并将在本地环境中构建。
This design may work for our teams, but it’s possible that we need a shared development environment in Azure, so we’d still need to give them higher permissions in the shared environment. Assigning permissions depends on our needs and there may be a use case where we want to give a team higher permission. For these cases, we want to consider how we audit such scenarios.
此设计可能适用于我们的团队，但可能需要在Azure中使用共享开发环境，因此我们仍然需要在共享环境中为他们提供更高的权限。 分配权限取决于我们的需求，并且在某些用例中，我们想给团队更高的权限。 对于这些情况，我们想考虑如何审核这种情况。
审核访问 (Auditing Access)
Where least permissions combine with audits is the warning sign that an account, multiple accounts, or something else has been disabled or is misfunctioning. Monitoring for Azure costs is one technique and we can also monitor the users who have access, their access level, and if users have been added or removed. This can be reflected in some of the following scenarios:
最少权限与审核相结合的警告标志是一个帐户，多个帐户或其他帐户已被禁用或发生故障。 监视Azure成本是一种技术，我们还可以监视具有访问权限的用户，其访问级别以及是否已添加或删除用户。 这可以反映在以下某些方案中：
- An attacker may compromise an account with significant permissions and disable all the accounts except the significant permissions account he’s using – but if one of those accounts is an audit account that becomes disabled, we may know through missing audits 攻击者可能会破坏具有重要权限的帐户，并禁用除他正在使用的重要权限帐户以外的所有帐户–但是，如果其中一个帐户是被禁用的审核帐户，我们可能会通过缺少审核来知道
- An attacker may compromise an account with significant permissions and create a new account for access that appears to be a normal part of our organization structure. However, we can audit for account access and detect and review when new accounts appear 攻击者可能会利用重要的权限来破坏帐户，并创建一个新的帐户来进行访问，这似乎是我们组织结构的正常组成部分。 但是，我们可以审核帐户访问权限，并在出现新帐户时进行检测和检查
- An attacker may compromise an account with significant permissions and conduct a man-in-the-middle attack where we receive audit information that is false, while the attack is causing damage (ie: our Azure costs are rising), but with audit information misleading us, we believe that we’re fine 攻击者可能会利用重要权限破坏帐户，并进行中间人攻击，在这种情况下，我们会收到不真实的审核信息，而该审核正在造成损害（即：我们的Azure成本不断增加），但审核信息具有误导性我们，我们相信我们很好
- An attacker may compromise an account with significant permissions and disable all accounts, except the monitoring account (or monitoring accounts). Likewise, the attacker may disable some accounts with less frequent access relative to the amount of prior reconnaissance 攻击者可能利用重要权限入侵一个帐户，并禁用除监视帐户（或多个监视帐户）以外的所有帐户。 同样，攻击者可能会禁用某些帐户，这些帐户的访问频率相对于先前侦察的数量要少
- Finally, an attacker may simply compromise an account with significant permissions and attack. Depending on what is wanted (such as information or causing damage through higher Azure costs), this may be more efficient even if caught quickly 最后，攻击者可能会利用大量权限和攻击来简单地破坏帐户。 根据需要的内容（例如信息或由于更高的Azure成本造成损害），即使快速发现，它也可能更有效
This doesn’t only provide us with information, it may also provide us with information if we’re not receiving information (missing audits, if the attacker disables monitoring accounts). In the case of the man-in-the-middle attack where the attacker both attacks and reports false information (Stuxnet-like), we can mitigate this by using independent audit resources – an App Service that self-reports with a user can be compromised in this manner with enough reconnaissance, whereas an independent server that performs a check must also be compromised too in order to report false information (increasing the points of attack for the attacker). In the below image we see the technique compared – on the left we see a design where a script on an app service self-audits Azure costs whereas on the right, we see an audit server that audits the App Service independently – the attacker must now compromise the audit server to poison our information.
这不仅可以为我们提供信息，还可以在我们没有收到信息的情况下为我们提供信息（缺少审计，如果攻击者禁用了监视帐户）。 在中间人攻击中，攻击者同时攻击并报告虚假信息（类似于Stuxnet），我们可以通过使用独立的审核资源来缓解这种情况–与用户自我报告的App Service可以以足够的侦察方式以这种方式破坏了安全性，而执行检查的独立服务器也必须被破坏以报告虚假信息（增加攻击者的攻击点）。 在下图中，我们看到了所比较的技术–左侧是设计，其中应用程序服务上的脚本可以自我审核Azure成本，而右侧，则可以看到审核服务器独立地审核App Service –攻击者现在必须破坏审核服务器以毒害我们的信息。
The idea behind the above design is that increased effort of an attack may dissuade an attacker relative to the reward of the attack – two points of an attack, especially when it required poisoning the data from one-point increases the effort. The effort to compromise one app service auditing users for protecting against potential attacks on Azure costs is less than an independent audit of this same information.
上述设计背后的思想是，增加攻击的工作量可能会使攻击者相对于攻击的报酬失去吸引力–攻击有两点，特别是当它需要从一个点中毒数据时，会增加工作量。 危害一个应用程序服务审核用户以防止对Azure成本进行潜在攻击的努力少于对该相同信息的独立审核。
In the below example PowerShell script, we perform an audit using the AzureRm PowerShell library by looking at the names, roles, types and their ability to delegate of our users. In the below script we output the details, but for auditing purposes, we may want to save these details to a file, table, or wrap it in logic that checks if conditions are true.
在下面的示例PowerShell脚本中，我们通过查看名称，角色，类型及其委派用户的能力，使用AzureRm PowerShell库执行审核。 在下面的脚本中，我们输出详细信息，但是出于审计目的，我们可能希望将这些详细信息保存到文件，表中，或者将其包装在检查条件是否为真的逻辑中。
$sub = "OurSubscriptionName"
$grp = "OurResourceGroup"
$srv = "hlthserver"
$type = "Microsoft.Sql/servers"
Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionName $sub
$details = Get-AzureRmRoleAssignment -ResourceGroupName $grp -ResourceName $srv -ResourceType $type
foreach ($detail in $details)
{
Write-Host (
"Name: " + $detail.DisplayName + ([Environment]::NewLine) +
"Definition: " + $detail.RoleDefinitionName + ([Environment]::NewLine) +
"Type: " + $detail.ObjectType + ([Environment]::NewLine) +
"Delegate: " + $detail.CanDelegate + ([Environment]::NewLine) +
([Environment]::NewLine)
)
}
How we audit will depend on how we design access – ultimately our findings should always confirm our design of least permissions. The above example would provide us with information on the user and access level along with whether these users can delegate, and we would adjust it if we wanted to audit other detailed information. As for specific accounts being compromised, auditing for credential protection may require other forms of testing.
我们如何审核将取决于我们设计访问权限的方式–最终，我们的发现应始终确认我们设计的权限最少。 上面的示例将为我们提供有关用户和访问级别的信息，以及这些用户是否可以委派，并且如果我们要审核其他详细信息，我们将对其进行调整。 对于被盗用的特定帐户，对凭据保护进行审核可能需要其他形式的测试。
凭据保护的安全测试 (Security Testing for Credential Protection)
In some cases, we have to acknowledge that a technical solution may not be sufficient for audits. Unfortunately, employees can have their credentials compromised through a variety of attacks, one being social engineering attacks, such as phishing, sim-swapping, etc. These attacks can be the entry point at which attackers can affect our Azure costs or other compromises through mimicking the permissions of the compromised account, which will appear to us as a legitimate user. Even if we follow strict permissions, there may be accounts that will need more permissions and these will always be a target for attackers.
在某些情况下，我们必须承认，技术解决方案可能不足以进行审计。 不幸的是，员工可能会通过各种攻击来破坏其凭据，其中一种是社会工程攻击，例如网络钓鱼，SIM卡交换等。这些攻击可能是攻击者可以通过模仿来影响我们的Azure成本或其他危害的切入点。被盗用帐户的权限，这些权限在我们看来将是合法用户。 即使我们遵循严格的权限，某些帐户可能仍需要更多权限，而这些帐户始终是攻击者的目标。
While it may be less technical, training employees against these social engineering attacks is one way to prevent these attacks. The trouble with technically skilled employees can be sometimes they overlook basic social engineering techniques (especially if the social engineering takes place in a physical environment). In the same manner, we may want to test employees by simulating scenarios that attackers will use – a security team intentionally sending phishing emails to identify who clicks through the email and exposes the company to risk. We should not underestimate the risk that social engineering can cost and as we’ve seen with many compromises recently, these attacks are increasing in frequency and sophistication.
尽管技术性可能较低，但是培训员工以使其免受这些社会工程攻击是防止这些攻击的一种方法。 技术熟练的员工遇到的麻烦有时是他们忽略了基本的社会工程技术（尤其是如果社会工程发生在物理环境中）。 以同样的方式，我们可能希望通过模拟攻击者将使用的方案来测试员工–安全团队有意发送网络钓鱼电子邮件，以识别谁点击了电子邮件，并使公司面临风险。 我们不应低估社会工程学可能造成的风险，并且正如我们最近在许多妥协中所看到的那样，这些攻击的频率和复杂性正在增加。
Whether the attackers want to affect our Azure costs, cause damage to our clients, or cause damage in other ways, attackers will always have an advantage over defensive systems because they only need to find one weakness – from our design to our employees. If we can identify this weakness before the attackers do, we remove an attack vector. This means we have to look at the entire range of attacks and test against the ones that may be outside development, such as social engineering.
无论攻击者希望影响我们的Azure成本，给我们的客户造成损害还是以其他方式造成损害，攻击者始终会比防御系统具有优势，因为他们只需要找到一个弱点-从我们的设计到我们的员工。 如果我们能够在攻击者之前识别出此弱点，则可以删除攻击媒介。 这意味着我们必须查看整个攻击范围，并针对可能是外部开发的攻击（例如社会工程学）进行测试。
结论 (Conclusion)
The cloud offers a convenient way to develop, test ideas, and possibly create architecture that we’ll use for our business at reduced cost. We may still face Azure cost risks alongside security, as attackers may compromise accounts and scale resources that increase our costs, or affect our clients with poor performance (ultimately hurting us). We should follow the least permissions principal by ensuring that all users have the least amount of access they need. In addition, we should monitor for users and keep track of all auditing – any missing audits may be a sign of an attack and the faster we identify it, the faster we can resolve
云提供了一种方便的方法来开发，测试构想，并可能创建可用于降低成本的业务架构。 我们可能仍会面临Azure成本风险和安全性问题，因为攻击者可能会破坏帐户并扩展资源，从而增加我们的成本，或以不良的性能影响我们的客户（最终伤害我们）。 我们应遵循最小权限原则，确保所有用户拥有所需的最少访问量。 此外，我们应该监视用户并跟踪所有审核-任何丢失的审核可能都是攻击的迹象，我们识别得越快，我们就能解决得越快
目录 (Table of contents)
| 具有安全性和设计注意事项的Azure成本跟踪 |
| 使用扩展和标签控制Azure成本 |
| 用户安全和Azure成本风险 |
| 使用PowerShell提取Azure成本 |
| 通过成本管理跟踪Azure成本 |
| 处理影响Azure成本的未使用和不必要的资源 |
| 查找影响Azure成本的未使用资源 |
| 我们可能需要更高的Azure成本的情况 |
翻译自: https://www.sqlshack.com/user-security-and-risks-to-azure-costs/
azure 安全组
1331
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
