本系列内容是我们在不同项目的维护过程中总结的关于DevOps/SRE方面的最佳实践，我们将旨在于在项目上尽最大的努力来实行这种最佳实践。我们希望这种最佳实践能对项目的稳定营运提供帮助，也希望刚接触DevOps/SRE的新人能通过学习这种最佳实践来提高自己在这方面的水平。
用户和权限管理对于维护一个安全可靠的基础设施和应用资源至关重要。在现今快节奏和协作的开发环境中，确保合适的人员拥有系统、资源和数据的适当访问权限极其重要。通过施行用户与权限管理实践，组织可以增加未经授权访问的风险，降低人为错误，强制执行安全控制，符合法规。
在本文中，我们将阐述一组最佳实践，包括给每位用户构建独立的帐号，给每位服务构建专用的帐号，减低使用特权帐号，使用角色而非用户帐号，定期进行轮换常年账簿的密码或访问秘钥，最小化权限原则，定期查看并移除未使用的用户、角色、权限等账簿，分离开发、测试和生产环境权限，使用强密码策略，使用多重验证，开启审计日志。以在Devops/SRE流程中构建坚实的用户和权限管理基础。通过遵守这种实践，您可以提升系统的安全性、效率和明晰责任，推动协作，并保持流程的简化。
给每位用户构建独立的帐号
在任何的系统中，我们都强烈建议给每位用户构建独立的帐号，而非使用共享帐号。相比共享帐号，独立帐号可以更明晰地界定用户的归属和权限，以便最小化权限管理，并降低帐号泄漏的风险。据悉，独立帐号还便捷后续的风险评估和操作审计等工作。
优点：
合法性检验：独立帐号可以检验用户身分的合法性以及对用户进行轮询
增强系统安全性：限制每位用户的权限可以维护系统的安全
提供个性化设置：为每位用户提供独到的体验，用户可依据其偏好进行自主设置
便捷审计：独立帐号可以便捷追踪每位用户的操作记录，有利于故障排查
减少损失范围：泄漏独立帐号后影响的范围更小
缺点：
降低管理成本：为每位用户分配独立帐号降低了管理复杂性
施行要点：
创建帐号时，须要有验证用户身分信息的资料，也可以考虑使用多诱因身分验证
提供用户的帐号恢复机制，用于应对用户忘掉密码等场景
权限应由专门的团队进行管理和分配
对于与项目相关的工具链(例如云平台，代码库房，CI/CD平台，项目管理工具等)，要对用户帐号进行统一管理，确保每位用户有独立的权限。小型公司可以使用第三方工具比如AzureAD来充当集中式的身分提供者和访问管理平台，将所有项目关联帐号统一管理便于管理员便捷的定义和执行一致的访问策略，管理用户配置和撤消，确保每位用户在集成平台上进行安全身分验证和授权。
保证用户离开团队时权限的销毁
给每位服务构建专用的帐号
一些手动化工具会须要和相关的系统/平台进行交互操作，大部份的系统/平台就会对类似的操作信令，因而这种工具也须要对应帐号来完成相应的验证。我们建议给类似的需求构建服务专用的帐号，为便捷管理，可以给帐号名称上加上一些表意的前后缀，例如svc或则machine_user等来分辨帐号的属性。
假如须要使用的第三方服务并不须要每位团队成员都注册帐号，我们建议使用一个管理专用而非个人所属邮箱等信息来注册，以防止团队成员变动带来的帐号未能保留等影响。
优点：
保证系统的安全性：若所有平台共用一个帐号，一旦被窃用所有的服务就会遭到功击
以便审计：便捷跟踪操作记录，有利于排查问题
精细化权限管理：增强对于不同服务权限管理的颗粒度
缺点：
降低管理成本：每位系统/平台须要单独创建帐号
不适用于所有系统：不太适宜大型系统
施行要点：
不使用用户token拉代替码
不与其他服务共用同一帐号/用户
构建帐号时要遵守最小权限原则，保证帐号只具有该服务所须要的权限
定期审计帐号的访问记录
施行示例：
以Github为例，在代码管理平台上为CI/CD平台的agent创建单独的帐户
以Nexus为例，在制品库平台上为CI/CD平台的agent创建单独的帐户。诸如，创建
-build-automation的用户来推送拉取建立镜像
降低使用特权(root)帐号
在任何系统的日常管理工作中，在非必要的情况下，我们强烈建议不要使用特权(root)帐号来进行操作。特权帐号具有系统所有权限，疏漏和不慎的操作有可能带来极大的损失。假如是在多人管理的情况下，也会降低帐号泄露的风险。同时，我们强烈建议对于特权帐号实施一切必要的安全管理，例如强密码，开启多重验证，及时的操作审计等。
优点：
提高安全性：一旦特权帐号泄漏，会造成系统数据被破坏或则被窃取
增加系统风险：若使用特权帐户不慎操作系统设置，可能会导致严重后果
缺点：
增加工作效率：个别工作若须要特殊权限，申请特权帐号会影响职工的工作效率
服务可能会形成异常：一些特殊服务须要特权帐号，普通用户帐号可能会造成系统或应用程序出现故障或不可用
施行要点：
保护和降低使用云服务帐号根用户（以AWS为例）
限制应用程序的权限
日常操作数据库时，应使用普通权限的帐号而非管理员帐号
加大对特权帐号的审计和监管
使用角色而非用户帐号
用户应当被分配到特定的角色，这种角色决定了她们在系统中的访问级别。不同的角色一般被赋于一系列不同的权限。一些平台，例如AWS，支持角色使用临时认证进行获取操作权限，所以我们建议在你的业务或则操作支持的情况下，使用角色(Role)而非用户帐号来完成对应的操作。
优点：
提高安全性：使用角色进行临时认证可以降低永久账簿的使用，因而减少潜在的安全风险。临时账簿在一段时间后会手动失效，降低了账簿泄漏或被滥用的风险
简化管理：角色的临时认证可以防止在每位用户帐号上设置和管理常年账簿的复杂性。相反，我们只需为角色配置适当的权限，并让用户通过临时账簿来获取访问权限。
增强灵活性：角色的临时认证容许按照须要授予用户临时的特定权限。这促使我们可以按需分配访问权限，并在不同的操作场景中灵活控制用户的权限级别。
缺点：
降低复杂性：角色的临时认证一般涉及更多的设置和配置步骤，相比直接使用用户帐号进行认证可能更为复杂。非常是对于初次接触和不熟悉角色概念的人员来说，这可能须要额外的学习和配置成本。
可用性和延后：因为临时账簿的过期时间，用户可能须要定期重新获取账簿以维持访问权限。这可能造成一些中断或延后，非常是在账簿过期前用户未及时获取新账簿的情况下。
授权复杂性：角色的临时认证可能须要更精细的权限设置和授权过程。您须要仔细定义和配置角色的权限范围，以确保用户具有足够的权限执行任务，同时防止过度授权造成安全风险。
平台限制：并非所有平台都支持角色的临时认证或具有相同的实现方法。在考虑使用角色进行临时认证时，须要确保目标平台支持并提供适当的功能和集成选项。
施行示例：
比如AWS：AWSIdentityandAccessManagement(IAM)提供了角色的临时认证功能。这促使我们可以便捷地创建角色，并使用临时账簿来获取对AWS资源的操作权限，而无需使用常年账簿（如用户名和密码）。以下是一个具体的事例：假定我们在AWS上有一个EC2实例，但是想要让该实例才能访问S3储存桶。以下是怎样使用角色进行临时认证的具体步骤：
通过使用角色的临时认证，可以防止在EC2实例上设置和管理常年账簿。相反，EC2实例可以通过角色来获取所需的临时账簿，但是这种账簿具有定义的S3访问权限。这增强了安全性，并简化了账簿管理过程。
请注意，上述示例仅适用于AWS，而且是一个具体的用例。其他平台和服务可能具有类似的功能和实现方法，但具体细节可能会有所不同。并且上述的步骤在实际的使用中是须要ascode的，拒绝任何人为的步骤。
比如Github：在Github中的组织中，我们可以创建团队，为团队分配权限和访问控制。通过创建团队，可以将一组人员组织在一起，并为她们分配某个代码库房的特定的权限角色，比如Admin/Write/Read等role，分别对应读取或写入等操作代码库房的权限。这样，我们可以更容易地管理团队成员的访问权限，而不是单独为每位成员设置权限。
对于常年账簿，定期轮换密码或访问秘钥
常年账簿（如密码、访问秘钥、证书等）是指用于身分验证和授权的账簿，它们被分配给个人或应用程序，便于它们可以访问系统或服务。常年账簿容易被偷用或窃取，倘若不及时轮换，可能会造成安全漏洞。定期轮换常年账簿是一种重要的安全管理举措，可以帮助组织减少风险，符合安全合规要求，避免不可撤消的访问权限，并提升安全意识。
优点：
控制外泄影响：通过限制可用周期降低账簿泄露形成的影响。
增加泄密范围：可以确定使用方的使用状态，清除未使用的账簿，增加泄露的范围。
符合标准：帮助系统通过PCI-DSS等强制标准。
缺点：
须要进行额外的操作：进行轮换时可能须要停止服务，对用户会有一定影响。
沟通成本高：可能须要与多方进行沟通，共同商定轮换时间，如有一方无法依照约定进行轮换，依然会对部份用户导致影响。
产生意外影响：进行轮换时可能会碰到预料之外的情况，如配置错误造成服务不可用。
降低管理成本：如须要密码管理器或是设备进行储存，须要配置额外的监控系统对轮换时间进行监控。
施行示例：
对须要轮换的账簿设置监控或通知，勿必确银监控或通知系统的可用性。
对更换周期要仔细掂量，没有适宜所有系统的最优解。
使用秘钥扫描工具对代码库进行扫描，防止代码中出现硬编码的秘钥，比如：
定期检测证书是否须要使用较新的cipher运行时错误没有权限，提高系统安全性。
记录和建立文档
最小化权限原则
最小化权限原则是指系统的每位程序或则用户都应当使用完成工作所需的最小权限工作。最小权限原则限制操作所需的权限，减少帐号或则系统在被恶意借助时导致的损失。因而在给帐号或则角色赋权时，尽可能只赋于操作所需的权限，应为用户提供履行其工作职责所需的最低访问级别，而非随便扩大权限范围，这有助于减少意外或故意滥用特权的风险。虽然我们须要给一些临时的操作赋权，也不要赋于何必要的额外权限，并在操作完成以后清除临时权限。如有可能，我们也建议新建临时帐号来完成这种操作，而非扩大原有帐号的权限。
优点：
降低安全漏洞的风险：在不存在加壳漏洞情况下，功击者只能执行对该用户所授权的操作。
限制数据泄漏的风险：同上，功击者只能访问该用户被容许的文件。
简化权限管理：减少对权限管理的工作量，可以快速确定使用范围。
以便审计：随时吊销清除何必要的权限，增加系统的功击面。
缺点：
降低管理的复杂性：虽然是使用权限组的情况下，仍有可能会降低管理的复杂性，尤其是存在较多权限组时。
影响工作效率：在限制访问的情况下，做一件复杂的事时可能须要反复切换帐号。
降低系统开发的成本：假如是正在开发中的系统，可能会降低系统开发的成本。
施行要点：
要权衡安全和效率的关系，对基础权限应主动给与，其他权限应评估后授予。
不给与太过空泛的权限，即便是用于测试，借以防止滥用的可能性。诸如：在使用CI布署AWSEC2实例时，不应当为了便捷而给与ec2:*这样的权限，而是应当仔细查看权限列表，只授予须要的最小权限列表。
应定期审查和更新权限，及时收回何必要的权限，增加功击和滥用风险。
对于Linux中的程序，必要时可使用AppArmor或是SELinux提高其权限管理。
定期查看并移除未使用的用户、角色、权限等账簿
我们建议定期去查看系统中是否有未被使用的账簿信息，假如发觉要及时进行清除或禁用，以避免毋须要的访问权限和潜在的安全风险，提升安全水平。
优点：
增加账簿泄露的影响：防止通过寻回初期生成的账簿对系统进行操作。
增加管理成本：对常年未使用的账簿进行清除可以简化系统的管理和审计过程。
降低混淆：可以直接专注于真正在使用中的用户、角色和权限。
缺点：
有删掉风险：维护的过程中有删掉的可能，有一定导致业务系统中断的风险。
降低工作量：须要定期检测，有对用户导致不便的可能，但对于多数系统来说一直是推荐的做法。
施行要点：
及时对未使用的账簿进行清除，以防止过度堆积导致审计负担。
在未确定是否仍在使用的情况下不要激进轻率地删掉账簿。
可以使用手动化工具对账簿进行扫描，对近日未使用的账簿/用户进行清除。诸如：对于AWS可配置AWSConfigiam-user-unused-credentials-check来辅助检测。
分离开发、测试和生产环境权限
我们日常大部份的工作场景都有多个环境，我们建议对于开发、测试和生产环境应当分别有不同的权限管理策略，以确保每位环境都具有正确的访问权限，而且不会影响其他环境的安全性。
优点：
提高生产环境的安全性：对生产环境权限的严格控制，可以最大限度地确保生产环境的安全，从权限上避免误操作造成脏数据、恶意删库等行为。
提高非生产环境的权限：不同的权限管理策略，可以最大化地给与开发人员和测试人员在开发、测试环境的权限。而且促使她们在不遭到权限限制影响的同时，也不用害怕会影响到生产环境的安全。
缺点：
紧急情况时流程复杂：当遇见特殊的线上问题且难以在其他环境复现时，假若此时没有足够的生产权限，则须要申请生产环境权限运行时错误没有权限，流程审批复杂时会浪费时间。
施行要点：
各个环境的权限应当由专门团队来统一管理和分发
对申请人的权限进行分发时须要经过该项目团队负责人的同意
权限的创建要遵守权限最小化原则，例如读写权限分离。
施行示例：
以AWS为例，对于布署在AWS上的服务，我们建议：
将开发，测试和生产环境帐号分开，布署在不同的AWSAccount里，实现整个环境的隔离
分别为用户在不同环境创建不同权限的IAMrole，比如：
使用强密码策略
我们强烈建议使用强密码策略，一个安全的密码应当不多于12个字符，起码有三种不同的字符，如数字，特殊字符，大小写字母。应防止在密码中包含个人信息，如出生日期或名子，宠物或乐团。还要避开歌词，伴侣和常用短语等。而且我们建议不要使用重复密码，尽可能在不同的系统中使用不同的密码，并定期更换密码。
优点：
增强安全性：使用强密码策略可以大大增强帐户的安全性。强密码一般更无法推测、破解或猜想，因而更难被恶意用户破解并获取对帐户的未授权访问。
避免撞库：在不同的系统中使用不同的密码，避免其他系统密码意外泄露后被砸库。
降低数据损失：假如密码发生泄露，定期更换密码可以降低数据损失。
降低密码泄漏风险：使用强密码策略可以降低密码泄漏的风险。强密码无法通过常见的功击手段（如字典功击、暴力破解、社交工程等）破解，进而增加帐户被黑客入侵的可能性。
缺点：
用户体验低：使用强密码策略可能会给用户带来不便。长、复杂的密码可能无法记忆，并可能须要时常修改密码。这可能造成用户重复使用密码、写下密码或寻求其他不安全的方式。
易忘掉密码：因为密码的复杂性，用户可能更容易忘掉密码。这可能造成密码重置的频度降低，给用户和支持团队带来额外的负担。
密码管理挑战：对于具有多个帐户和复杂密码要求的用户来说，管理和记忆所有密码可能成为挑战。这可能造成用户使用密码管理器或其他手动化工具，或则采用不安全的解决方案。
施行示例：
比如AWS：可以在AWSIAM中设置如下的用户密码策略，任何用户的密码必须遵循设置的策略：
使用多重验证(MFA)
多重验证(MFA)是一个额外的安全举措，要求用户在被授予系统访问权限之前提供多种方式的身分验证。这可能包括发送到手机或其他设备的密码或代码。假如对应的系统支持多重验证，我们建议开启使用多重验证功能。但是不要把密码管理工具和MFA工具安装在同一设备上。
优点：
提供多层保障：可以提升帐户的安全保障，假如密码不留神泄露，多重验证可以提供第二层保护。
帐户失窃可能性最小化：因为MFA可能是脸部辨识、指纹或则一次性密码，所以被窃取的可能性十分小。
避免帐户绑架：多重验证可以有效避免恶意用户绑架别人的帐户。不仅晓得密码外，功击者还须要访问用户所拥有的其他验证诱因，能够成功假扮用户。
合规性要求：在个别行业和法规中，使用多重验证可能是强制性的要求。诸如，支付卡行业（PCIDSS）对进行支付交易的帐户要求启用多重验证。
缺点：
用户体验琐碎：使用多重验证可能会降低用户登入过程的复杂性和时间。用户须要提供额外的验证诱因，并可能须要额外的设备或应用程序来完成验证。
依赖额外设备：个别多重验证方式可能须要额外的硬件设备（如硬件令牌）或应用程序（如身分验证器应用程序）。用户须要确保那些设备或应用程序可靠，并妥善保管。
遗失或破损的设备：假如用户的多重验证设备遗失或破损，她们可能会面临帐户被锁定的风险。在这些情况下，恢复访问帐户可能须要额外的步骤和时间。
施行要点：
选择适当的验证诱因：确定适宜我们当前环境和用户的验证诱因类型。常见的验证诱因包括密码、手机验证码、硬件令牌、身份验证器应用程序（如GoogleAuthenticator）和生物辨识（如指纹或脸部辨识）。按照实际需求和安全要求，选择一个或多个验证诱因。推荐使用硬件秘钥提高安全性和易用性，尽量不使用邮件验证方法。
启用强制性多重验证：对于敏感帐户和重要权限的用户，应强制启用多重验证。确保所有用户了解并遵循多重验证新政，以保护帐户的安全。
必要情况下可以强制添加两种及以上的多重验证
开启审计日志
假如你的系统支持记录审计日志，我们建议开启审计日志并保存起码半年的记录。审计日志本身是法律刚性需求，是安全合规性检测的必备材料之一。
优点：
安全监控：审计日志提供了对环境活动和操作的完整可见性，才能监控和检查潜在的安全恐吓、漏洞或异常行为。
审计和合规性：审计日志可以用于满足合规性要求，并支持安全审计和调查。它们记录了谁在何时进行了哪些操作，为初审和合规性证明提供了关键的根据。
故障排除和故障恢复：审计日志可以帮助我们进行故障排除，追踪问题的症结，并支持故障恢复过程。
调查和取证：审计日志可以用于调查安全风波、追踪功击来源以及为法律或法规要求搜集证据。
剖析和洞察：审计日志提供了对环境活动的可溯源记录，可以用于剖析和获取有关资源使用、访问模式和行为趋势的洞察。
缺点：
储存成本降低：启用审计日志可能会降低储存成本，尤其是在有大量活动和常年保留需求的情况下。储存和保留审计日志可能须要额外的资源和成本。
处理复杂性：审计日志可能会形成大量的风波和日志数据，须要适当的工具和技术来处理和剖析这种数据。处理大量的日志数据可能须要投入时间和资源。
隐私和合规性考虑：审计日志可能包含敏感信息，因而必须遵循适用的隐私和合规性要求，比如数据保护和数据保留新政。
施行要点：
选择合适的审计日志工具：比如：在AWS上，可以使用AWSCloudTrail来记录和监控环境的活动。确保正确配置和启用CloudTrail，并按照需求设置适当的日志保留时限和储存位置。
定义审计日志策略：制订和文档化审计日志策略，明晰记录什么活动和风波应当被审计。按照实际需求和合规性要求，确定须要记录的资源类型、操作类型和级别。
初审访问权限：审查和验证用户和角色的访问权限，确保只有授权的实体才能访问和更改审计日志。采用最小特权原则，仅授予必要的权限以避免潜在的滥用。
配置日志储存和保留期：确定审计日志的储存位置和保留期。按照合规性要求和业务需求，选择适当的储存服务和设置合理的保留时限。
配置手动化审计策略，实时监控和警报：构建实时监控和警报机制，便于对重要的活动和风波及时作出响应。诸如使用AWSCloudWatch、AWSEventBridge或其他警报服务来监控审计日志，检查异常或可疑的活动。
日志剖析和可视化：使用适当的日志剖析工具和技术，对审计日志进行剖析、搜索和可视化。这有助于快速发觉潜在的安全恐吓、异常行为或合规性问题。
定期审查和检测：定期审查审计日志，检测活动和风波的记录，并及时调查任何异常或可疑的情况。按照须要，更新和改进审计日志策略和设置。
合规性要求：按照适用的合规性要求（如GDPR、HIPAA、PCIDSS等），确保审计日志的施行符合相关标准和规定。
培训和意识：提供培训和意识活动，确保相关人员了解审计日志的重要性、使用方式和最佳实践。培养团队对审计日志的积极心态和有效借助。审计应当由不同的人员执行，以确保权限分配的公平性和确切性。
持续改进：按照实际情况和反馈，持续改进审计日志施行。定期评估并更新审计日志策略、工具和流程，以适应变化的需求和恐吓。
谢谢
特别谢谢田鼎义，赵浩，周加大参与本章的撰写。
