云安全实用指南-Practical Cloud Security
文章来自 https://www.cnblogs.com/iAmSoScArEd/p/13034141.html 我超怕的 转载请注明出处。
最小权限
默认全部权限为拒绝，用户默认被授予无任何权限（或极小权限）。按需申请权限。
严格控制云控制台权限，并且记录用户的行为。
深度防御
威胁来源、威胁示意图及信任边界
一、明确什么需要被保护，明确谁可能会带来风险。（潜在风险源头）
-
违法组织或个人，主要目的赚钱。
-
黑客，主要目的窃取数据、破坏、扰乱正常业务。
-
内部人员，主要目的报复或赚钱
-
国家行动人员，主要目的窃取机密、扰乱正常业务。
在设计与思考防御措施时要时刻警惕以上风险人群。
二、构建风险示意图，来直观的发现安全防御的不足之处。用信任边界来区分不同角色在不同系统中的权限。
云安全责任划分
无论哪种方式，数据的访问安全永远是我们所负责的。
第四章 身份和访问管理
授权（Authorization）是为了核查你的角色或身份，并检查你是否有权限访问某个区域或区域内的某些功能。
通常很多时候在开通账号时授予了所有权限，并且是通过删除某人的身份来限制访问权限。应通过限制账号能够访问的区域以及功能来限制权限。
减少信任的组织或人员数量，来减少风险。
与传统管理的区别
传统的访问控制都是基本的物理访问控制、网络访问控制，但是却容易忽略以太网接口或泄漏vpn认证，因此有可能以任何方式联入内网等。
传统的访问管理是以删除账号来限制访问，但是在云环境不行，因为在某些服务中可能会生成一个有效期很长的“令牌”，依然可以用令牌来访问某些内容。
有部分信息泄漏的原因是云服务商（书中举例的亚马逊）的web服务的公共访问权限导致。
身份和访问的生命周期
IAM（身份和访问管理）不仅仅是做身份验证和授权。
IAM还需要在当有人请求访问服务时，应记录访问者是怎么认证的，谁授予的身份和访问权限。
更重要的是这一生命周期的末端，需要一个系统定期自动检查每一个用户的身份和访问是否仍然需要进行权限回收。（或许有人离职或转去其他部门后长时间没有访问，或更糟的是解雇（双方都不愉快的那种）某人后，很久才意识到没有收回账号权限。）
参考下图最为简单的IAM生命周期
下面对每个阶段进行详细的说明
请求
通常请求为以下四种：
Create：创建一个身份(通常会隐式地授予该身份至少一个基本访问级别)。
Delete：如果实体不再需要在任何地方进行身份验证，则删除身份。
Grant：授予对现有身份某些系统的访问权。
Revoke：撤销现有身份的访问权限。
审批
某些场景允许绝对的访问权限开放，如：Web应用程序
在内部组织中的大多数访问请求权限都应该进行明确的审批。在大多数情况下，有两个审批是合理的：用户的直接主管（the user’s immediate supervisor ），以及被访问系统的所有者（as well as the owner of the system to which access is being requested）。重要的是审批或者审批人能够清楚的知道这个访问权限审批是否合理和必要。
创建、删除、授权、撤销
批准之后，创建身份、删除身份、授予访问权或撤消访问权的实际操作可能会自动发生。例如，请求/批准系统可能使用云提供商api来创建标识或授予访问权限。
在其他情况下，这可能会生成一个票据、电子邮件或其他通知，以便某人采取手动操作。例如，另一个管理员可以登录到云门户来创建新身份，并授予它一定级别的访问权限。
认证
区分需要认证的对象也很重要，通常有以下几个系统：
使用云提供商对组织的员工进行身份验证(通常是企业对企业，云提供商通常称之为“Cloud IAM”之类的东西)
使用自己的应用程序验证客户(企业对用户)
使用自己的应用程序验证组织的员工(企业对员工)
Cloud IAM
许多云提供商提供IAM服务。这些系统允许您拥有一个中心控制权来管理组织中云管理员的身份，以及将这些身份授予云提供商提供的所有服务的访问权。
这是一个非常有用的服务。如果您使用来自云提供商的数十个或数百个服务，就很难清楚地了解特定人员的访问级别。当某个人离开组织时，很难保证你已经删除了他们所有的身份。如前所述，删除访问权限是特别重要的，因为许多服务是面向外网开放的。
企业-用户和企业-员工
有两个较好的认证方式选择：
-
使用已经存在的身份认证系统：如腾讯qq、微博、微信等
-
对应用程序使用一个完善的自定义的认证
可以了解一下IDaaS（Identity-as-a-Service）
MFA
MFA是目前最好的办法来解决弱认证或认证信息被盗的情况。
目前的多因子包括：
-
知道的事物（Something you know） 如：密码
-
拥有的事物（Something you have） 如：手机号
-
唯一的特征（Something you are） 如：指纹、面部特征
SSO使用双因子认证
目前使用的双因子认证方式有：
-
短信验证码：存在SIM克隆或其他被盗的风险，或者验证码被拦截。新的验证应不使用SMS，推荐使用网络来接收验证码。
-
基于时间的一次性密码（TOTPs）：允许在任何设备登录并获取，因此需要把它放到一个安全的物理环境中。
-
推送消息认证：在一个认证过的设备上在需要的时候推送一个一次性认证码或认证消息。
-
硬件设备：使用满足FIDO U2F标准的硬件设备在需要的时候生成一条有实效的密码。
密码和API Key
设置一个什么样的密码：
-
绝对不要重复使用同一个密码在不同的地方。
-
不使用相同的密码意味着需要建立多个密码，因此可以使用密码管理工具来帮助你记录它们。
-
你不用去记住密码了，因此将密码的长度设置为20是一个不错的选择。
-
然后在密码中随机穿插一些特殊字符如：&$%#*!?等。
API keys与密码非常相似，但是它是设计给自动化程序使用的。因此你无法使用双因子认证来配合使用API keys，它的设计是一个长的随机字符串。不像大多数常见的用户身份，有一个公共的用户ID和私人的密码，API keys仅使用一个API Key来进行标识和认证。
sercets管理
secrets管理的注意事项：
-
secrets应该很容易更改，以便在得知或认为它可能泄漏以后能够快速修改，减少损失。
-
应该始终保持secrets是被加密的，无论是在初始还是传输中。并且要保证secrets是在合适的认证之后才进行分发。
-
如果可能，应该尽可能做到没有人知道这个secrets，包括写代码的开发者，有权限查看运行系统的操作人员等。
-
系统在存储或者分发的过程中secrets应该被保护。不能分发给太多人。
-
保证系统正常功能的前提下，尽可能地让secrets在攻击者手上没有什么用途。
-
所有访问、修改secrets的行为都应该被记录
Secret管理的四种合理方法:
第一种方法仅在部署系统中存储secrets，使用旨在保存secrets的特性，并严格控制对部署系统的访问。在默认情况下，没有人会看到这些secrets，只有经过授权的个人才能在部署系统中查看或更改它们。
第二种方法是使用secrets服务器来保存secrets。部署服务器或部署的应用程序将与secrets服务器联系，以获取必要的secrets并使用。在许多情况下，在部署之后，secrets仍然可以在运行的应用程序的配置文件中看到，因此操作人员可以轻松地查看secrets或secrets服务器的凭据。
-
secrets服务器应该能对发来的请求做记录，需要去检查和阻止一个未授权的用户或应用访问secrets。
-
访问secrets服务器的认证方法应该除了密码外还有其他的手段，如：ip范围，可以添加一个ip白名单。
-
在之后可以很轻松的更新这些secrets，并且你的系统将会自动去获取最新的secrets。
第三种方法使部署服务器只能获得一次性令牌并将其传递给应用程序，然后应用程序检索secrets并将其保存在内存中。这将保护您免受secrets服务器或secrets本身的凭据被截获。
-
这种方法具有secrets服务器的所有优点，此外还使用了一种安全的引入方法，以减少攻击者获得访问secrets服务器的凭据的可能性
-
您的部署工具与secrets服务器进行通信，以获得一次性使用的secrets，并将其传递给应用程序。
-
然后，应用程序将这些信息交换到secrets服务器，并使用这些信息获取所需的所有其他secrets并将其保存在内存中。如果有人已经使用了这个一次性的secrets，这个步骤就会失败，应用程序就会发送错误警告。
第四种方法利用云提供商本身作为信任的基础。云提供商提供可信的身份文档和元数据，secrets服务器可以使用这些文档和元数据“决定向每个应用程序提供哪些secrets”。
-
一些云提供商为云中供应的系统提供实例元数据或身份文档。您的应用程序可以检索这个身份文档，它将显示类似“我是A服务器”这样的内容。云提供商使用密码为我签署了这份文件，证明了我的身份。”
-
之后，secrets服务器知道服务器的身份，以及关于服务器的标记等元数据后，secrets服务器可以使用这些信息对服务器上运行的应用程序进行身份验证和授权，并为其提供所需的其余secrets。
授权
集中授权
旧的、临时的将身份分散到各处的做法已经通过联合身份和SSO解决了。但是，您可能仍然有分散在各处的授权记录，每个应用程序都可能保留自己的记录谁可以在该应用程序中执行操作。
您可以通过删除某人的身份来完全取消其权限（假设持久访问令牌在一段时间内未对其进行授权），但是仅取消部分访问权限的能力怎么样？删除某人身份的能力很重要，但这是执行访问管理的一种非常繁重的方法。您通常需要更精细的方法来管理访问。集中授权可以让您查看和控制用户可以访问的具体的哪些内容。
在传统的应用程序中，所有的授权工作都是在应用程序内部执行的。在集中式授权的世界中，职责通常在应用程序和集中式授权系统之间划分。在一些系统中有更多的细节，但以下是基本组件：
-
策略执行点（PEP Policy Enforcement Point）
这一点在应用程序中实现，应用程序控制访问。如果您在策略中没有指定的访问权限，则服务或应用程序将不允许您执行该功能。应用程序通过向策略决策点请求决策来检查访问。
-
策略决策点（PDP Policy Decision Point）
这一点是在集中授权系统中实现的。PDP获取应用程序提供的信息（如身份和请求的功能），查询其策略，并向应用程序提供是否授予该特定功能访问权限的决策。
-
策略管理点（PAP Policy Administration Point）
这一点也在集中授权系统中实现。这通常是一个web用户界面和相关的API，在这里您可以告诉集中授权系统谁可以做什么。”
大多数云提供商都有一个集中的访问管理解决方案，他们的服务将咨询这个访问决策，而不是服务提供商自己做决策。您应该在可用的情况下使用这些机制，以便可以在一个位置查看授予特定管理员的所有访问权限。
角色
许多云提供商提供角色，这与共享id类似，因为您承担角色、执行角色允许的操作和删除角色。这与传统的角色实现略有不同，后者是一组永久授予用户或组的权限。
共享ID和角色之间的主要区别在于，共享ID是具有固定凭据的独立标识。云提供程序角色不是完全标识；它是另一个被授权访问角色的标识所接受的特殊状态，然后被分配临时凭据来访问该角色。
基于角色的访问可以添加额外的安全层，方法是要求用户或服务按照最小权限原则显式地为更多特权操作承担单独的角色。大多数情况下，用户无法执行这些特权活动，除非他们明确地扮演“帽子”角色，并在完成任务时将其摘下。系统还可以记录每个请求以接受某个角色，以便管理员以后可以确定在特定时间谁具有该角色，并将该信息与系统上具有安全后果的操作进行比较。
人并不是唯一可以扮演角色的实体。某些组件（如虚拟机）可以在创建时承担一个角色，并使用分配给该角色的权限执行操作。
重新验证
在这一点上，您的用户和自动化系统应该具有身份，并被授权只做他们需要做的事情。你需要确保它经得起时间的考验。
如前所述，重新验证步骤在传统环境和云环境中都非常重要，但在云环境中，如果忘记撤消访问，则可能没有任何附加的控制（如物理建筑访问或网络控制）来保存。您需要定期检查每个授权，以确保它仍然需要存在。
第一种重新验证是基于某些参数的自动再验证。例如，您应该有一个系统，当有人离开组织时，该系统会自动请求撤消所有访问权。请注意，仅仅删除用户的标识可能是不够的，因为用户可能具有缓存的凭据，例如访问令牌，即使没有登录能力也可以使用这些凭据。在这种情况下，您需要一个“offboardfeed”，它是一个应该撤销其访问权限的实体列表。任何分发长寿命凭据（如访问令牌）的系统都必须至少每天处理此脱离源并撤消所有访问。
第二种重新验证需要人类判断，以确定某个特定实体是否仍需要访问。通常有两种基于判断的再验证：
-
肯定性确认
指该访问权限将丢失，除非有人明确表示，“仍然需要访问。”
-
否定性确认
指该访问权限将被保留，除非有人说“不再需要这个访问”
否定性确认适用于影响较小的授权级别，但对于对业务影响较大的访问类型，应使用肯定性确认。肯定确认的缺点是它会有更多的工作量，如果请求没有及时处理（这可能会导致操作问题），访问可能会被意外地撤销。
重新验证所解决的最大风险是，离开组织的人（可能存在有争议的情况下）保留对系统的访问权。除此之外，随着时间的推移，访问往往会积累，就像厨房垃圾抽屉里的垃圾一样。重新验证可以清除这些垃圾。
还需要注意的是，可能会存在询问使用者是否需要使用时可能他们会在不需要的情况下仍然说自己需要。如果有一个快速而且简单的一个申请访问权限的流程，那么我们可以不用担心直接进行移除那些一段时间没有使用的访问权限，而不是再去询问。
除了身份验证和授权服务之外，云身份即服务（Identity-as-a-Service）产品正日益提供对整个身份生命周期的管理。换言之，服务提供者正在认识到结束关系和开始关系的重要性，他们正在帮助简化和规范 生命周期中的结束这一阶段。
整体IAM示意图
附：腾讯云最佳实践指南
1.开启 MFA 保护
为增强账号安全性，建议您为所有账号绑定 MFA；为主账号及子账号都开启登录保护和敏感操作保护。对于支持邮箱登录或者微信登录的强烈推荐进行 MFA 二次验证。开启 MFA 后，账号登录及敏感操作需进行二次校验。相关设置请参考：为协作者设置安全保护、为子用户设置安全保护。
2.使用子账号访问腾讯云
请尽量不要使用主账号的身份凭证访问腾讯云，更不要将身份凭证共享给他人。一般情况下，应该为所有访问腾讯云的用户创建子账号，同时授权该子账号相应的管理权限。相关设置请参考：用户类型。
3.使用组给子账号分配权限
按照工作职责定义好组，并给组分配相应的管理权限。然后把用户分配到对应的组里。这样，当您修改组的权限时，组里相关用户的权限随即发生变更。另外，当组织架构发生调整时，只需要更新用户和组的关系即可。相关设置请参考：用户组。
4.最小权限原则
最小权限原则是一项标准的安全原则。即仅授予执行任务所需的最小权限，不要授予更多无关权限。例如，一个用户仅是 CDN 服务的使用者，那么不需要将其他服务的资源访问权限（如 COS 读写权限）授予给该用户。
5.分子账号管理用户、权限和资源
建议同一个子账号不同时管理用户、权限和资源。应该让部分子账户管理用户，部分子账号管理权限，部分子账号管理其他云资源。
6.定期轮转身份凭证
建议您或 CAM 用户要定期轮换登录密码或云 API 密钥。这样可以让身份凭证泄漏情况下的影响时间受限。 主账号密码设置请参考：账号密码。 子用户密码设置请参考：子用户重置密码。
7.删除不需要的证书和权限
删除用户不需要的证书以及用户不再需要的权限。尽量减少访问凭证泄漏后带来的安全风险。
8.使用策略条件来增强安全性
