作者| 趙佩

本系列內(nèi)容是我們在不同項(xiàng)目的維護(hù)過程中總結(jié)的關(guān)于 DevOps/SRE 方面的最佳實(shí)踐，我們將致力于在項(xiàng)目上盡最大的努力來推行這些最佳實(shí)踐。我們希望這些最佳實(shí)踐能對項(xiàng)目的穩(wěn)定運(yùn)營提供幫助，也希望剛接觸 DevOps/SRE 的新人能通過學(xué)習(xí)這些最佳實(shí)踐來提升自己在這方面的水平。

用戶和權(quán)限管理對于維護(hù)一個(gè)安全可靠的基礎(chǔ)設(shè)施和應(yīng)用資源至關(guān)重要。在當(dāng)今快節(jié)奏和協(xié)作的開發(fā)環(huán)境中，確保合適的人員擁有系統(tǒng)、資源和數(shù)據(jù)的適當(dāng)訪問權(quán)限非常重要。通過實(shí)施用戶與權(quán)限管理實(shí)踐，組織可以降低未經(jīng)授權(quán)訪問的風(fēng)險(xiǎn)，減少人為錯(cuò)誤，強(qiáng)制執(zhí)行安全控制，符合法規(guī)。

在本文中，我們將探討一組最佳實(shí)踐，包括給每個(gè)用戶建立獨(dú)立的賬號，給每個(gè)服務(wù)建立專用的賬號，減少使用特權(quán)賬號，使用角色而非用戶賬號，定期進(jìn)行輪換長期憑證的密碼或訪問密鑰，最小化權(quán)限原則，定期查看并移除未使用的用戶、角色、權(quán)限等憑證，分離開發(fā)、測試和生產(chǎn)環(huán)境權(quán)限，使用強(qiáng)密碼策略，使用多重驗(yàn)證，開啟審計(jì)日志。以在 Devops/SRE 流程中建立堅(jiān)實(shí)的用戶和權(quán)限管理基礎(chǔ)。通過遵循這些實(shí)踐，您可以提高系統(tǒng)的安全性、效率和明確責(zé)任，促進(jìn)協(xié)作，并保持流程的簡化。

給每個(gè)用戶建立獨(dú)立的賬號

在任何的系統(tǒng)中，我們都強(qiáng)烈建議給每個(gè)用戶建立獨(dú)立的賬號，而非使用共享賬號。相比共享賬號，獨(dú)立賬號可以更明確地劃分用戶的歸屬和權(quán)限，便于最小化權(quán)限管理，并減少賬號泄露的風(fēng)險(xiǎn)。此外，獨(dú)立賬號還方便后續(xù)的風(fēng)險(xiǎn)評估和操作審計(jì)等工作。

優(yōu)點(diǎn)：

• 合法性檢驗(yàn)：獨(dú)立賬號可以檢驗(yàn)用戶身份的合法性以及對用戶進(jìn)行鑒權(quán)
• 提高系統(tǒng)安全性：限制每個(gè)用戶的權(quán)限可以維護(hù)系統(tǒng)的安全
• 提供個(gè)性化設(shè)置：為每個(gè)用戶提供獨(dú)特的體驗(yàn)，用戶可根據(jù)其偏好進(jìn)行自主設(shè)置
• 方便審計(jì)：獨(dú)立賬號可以方便追蹤每個(gè)用戶的操作記錄，有利于故障排查
• 減小損失范圍：泄露獨(dú)立賬號后影響的范圍更小

缺點(diǎn)：

• 增加管理成本：為每個(gè)用戶分配獨(dú)立賬號增加了管理復(fù)雜性

實(shí)施要點(diǎn)：

• 創(chuàng)建賬號時(shí)，需要有驗(yàn)證用戶身份信息的資料，也可以考慮使用多因素身份驗(yàn)證
• 提供用戶的賬號恢復(fù)機(jī)制，用于應(yīng)對用戶忘記密碼等場景
• 權(quán)限應(yīng)由專門的團(tuán)隊(duì)進(jìn)行管理和分配
• 對于與項(xiàng)目相關(guān)的工具鏈(例如云平臺(tái)，代碼倉庫，CI/CD 平臺(tái)，項(xiàng)目管理工具等)，要對用戶賬號進(jìn)行統(tǒng)一管理，確保每個(gè)用戶有獨(dú)立的權(quán)限。大型公司可以使用第三方工具例如 Azure AD 來充當(dāng)集中式的身份提供者和訪問管理平臺(tái)，將所有項(xiàng)目關(guān)聯(lián)賬號統(tǒng)一管理以便管理員方便的定義和執(zhí)行一致的訪問策略，管理用戶配置和撤銷，確保每個(gè)用戶在集成平臺(tái)上進(jìn)行安全身份驗(yàn)證和授權(quán)。
• 保證用戶離開團(tuán)隊(duì)時(shí)權(quán)限的銷毀

給每個(gè)服務(wù)建立專用的賬號

一些自動(dòng)化工具會(huì)需要和相關(guān)的系統(tǒng)/平臺(tái)進(jìn)行交互操作，大部分的系統(tǒng)/平臺(tái)都會(huì)對類似的操作鑒權(quán)，因此這些工具也需要對應(yīng)賬號來完成相應(yīng)的驗(yàn)證。我們建議給類似的需求建立服務(wù)專用的賬號，為方便管理，可以給賬號名稱上加上一些表意的前后綴，比如 svc 或者machine_user 等來區(qū)分賬號的屬性。

如果需要使用的第三方服務(wù)并不需要每個(gè)團(tuán)隊(duì)成員都注冊賬號，我們建議使用一個(gè)管理專用而非個(gè)人所屬郵箱等信息來注冊，以避免團(tuán)隊(duì)成員變動(dòng)帶來的賬號無法保留等影響。

優(yōu)點(diǎn)：

• 保證系統(tǒng)的安全性：若所有平臺(tái)共用一個(gè)賬號，一旦被盜用所有的服務(wù)都會(huì)受到攻擊
• 便于審計(jì)：方便跟蹤操作記錄，有利于排查問題
• 精細(xì)化權(quán)限管理：提高對于不同服務(wù)權(quán)限管理的顆粒度

缺點(diǎn)：

• 增加管理成本：每個(gè)系統(tǒng)/平臺(tái)需要單獨(dú)創(chuàng)建賬號
• 不適用于所有系統(tǒng)：不太適合小型系統(tǒng)

實(shí)施要點(diǎn)：

• 不使用用戶 token 拉取代碼
• 不與其他服務(wù)共用同一賬號/用戶
• 建立賬號時(shí)要遵循最小權(quán)限原則，保證賬號只具有該服務(wù)所需要的權(quán)限
• 定期審計(jì)賬號的訪問記錄

實(shí)施示例：

(1)以 Github 為例，在代碼管理平臺(tái)上為 CI/CD 平臺(tái)的 agent 創(chuàng)建單獨(dú)的賬戶

• 對于 agent 要拉取代碼倉庫的場景，我們建議：創(chuàng)建賬戶名為 svc_machine 的單獨(dú)賬號，并為該賬戶授予所需存儲(chǔ)庫的讀權(quán)限來拉取代碼
• 如果在 agent 上有寫倉庫的需求，例如 push 代碼或者打標(biāo)簽，我們建議：有需求的倉庫給對應(yīng)的 agent 創(chuàng)建獨(dú)立的 deploy key，并給該 key 賦予寫權(quán)限，同時(shí)對 ssh key 進(jìn)行加密保存

(2)以 Nexus 為例，在制品庫平臺(tái)上為 CI/CD 平臺(tái)的 agent 創(chuàng)建單獨(dú)的賬戶。例如，創(chuàng)建 <project-name>-build-automation 的用戶來推送拉取構(gòu)建鏡像

減少使用特權(quán)(root)賬號

在任何系統(tǒng)的日常管理工作中，在非必要的情況下，我們強(qiáng)烈建議不要使用特權(quán)(root)賬號來進(jìn)行操作。特權(quán)賬號具有系統(tǒng)所有權(quán)限，疏忽和不慎的操作有可能帶來極大的損失。如果是在多人管理的情況下，也會(huì)增加賬號泄漏的風(fēng)險(xiǎn)。同時(shí)，我們強(qiáng)烈建議對于特權(quán)賬號施行一切必要的安全管理，比如強(qiáng)密碼，開啟多重驗(yàn)證，及時(shí)的操作審計(jì)等。

優(yōu)點(diǎn)：

• 提升安全性：一旦特權(quán)賬號泄露，會(huì)導(dǎo)致系統(tǒng)數(shù)據(jù)被破壞或者被盜取
• 降低系統(tǒng)風(fēng)險(xiǎn)：若使用特權(quán)賬戶不慎操作系統(tǒng)設(shè)置，可能會(huì)造成嚴(yán)重后果

缺點(diǎn)：

• 降低工作效率：某些工作若需要特殊權(quán)限，申請?zhí)貦?quán)賬號會(huì)影響員工的工作效率
• 服務(wù)可能會(huì)產(chǎn)生異常：一些特殊服務(wù)需要特權(quán)賬號，普通用戶賬號可能會(huì)導(dǎo)致系統(tǒng)或應(yīng)用程序出現(xiàn)故障或不可用

實(shí)施要點(diǎn)：

(1)保護(hù)和減少使用云服務(wù)賬號根用戶（以 AWS 為例）：

• 在創(chuàng)建 AWS 賬戶時(shí)，會(huì)有一個(gè)根用戶名和密碼，以登錄 AWS Management Console。不建議為該根用戶生成訪問密鑰，也不要將根用戶用于日常任務(wù)。
• 僅使用根用戶執(zhí)行那些只能由 root 用戶執(zhí)行的任務(wù)，創(chuàng)建其他專門的用戶來執(zhí)行其他任務(wù)

(2)限制應(yīng)用程序的權(quán)限

• 容器中的服務(wù)盡量使用普通賬號：在編寫 Dockerfile 時(shí)，使用 USER 關(guān)鍵字限定使用運(yùn)行的專用賬戶，避免使用 root 用戶。
• 避免使用特權(quán)模式：在容器啟動(dòng)時(shí)，不要使用特權(quán)模式（如--privileged選項(xiàng)），以限制容器的權(quán)限。
• 如果使用 Kubernetes，則可以 在 securityContext 中增加 allowPrivilegeEscalation: false 避免容器越權(quán)

(3)日常操作數(shù)據(jù)庫時(shí)，應(yīng)使用普通權(quán)限的賬號而非管理員賬號

(4)加強(qiáng)對特權(quán)賬號的審計(jì)和監(jiān)管

使用角色而非用戶賬號

用戶應(yīng)該被分配到特定的角色，這些角色決定了他們在系統(tǒng)中的訪問級別。不同的角色通常被賦予一系列不同的權(quán)限。一些平臺(tái)，比如AWS，支持角色使用臨時(shí)認(rèn)證進(jìn)行獲取操作權(quán)限，所以我們建議在你的業(yè)務(wù)或者操作支持的情況下，使用角色 (Role) 而非用戶賬號來完成對應(yīng)的操作。

優(yōu)點(diǎn)：

• 增強(qiáng)安全性：使用角色進(jìn)行臨時(shí)認(rèn)證可以減少永久憑證的使用，從而降低潛在的安全風(fēng)險(xiǎn)。臨時(shí)憑證在一段時(shí)間后會(huì)自動(dòng)失效，減少了憑證泄露或被濫用的風(fēng)險(xiǎn)
• 簡化管理：角色的臨時(shí)認(rèn)證可以避免在每個(gè)用戶賬號上設(shè)置和管理長期憑證的復(fù)雜性。相反，我們只需為角色配置適當(dāng)?shù)臋?quán)限，并讓用戶通過臨時(shí)憑證來獲取訪問權(quán)限。
• 提高靈活性：角色的臨時(shí)認(rèn)證允許根據(jù)需要授予用戶臨時(shí)的特定權(quán)限。這使得我們可以按需分配訪問權(quán)限，并在不同的操作場景中靈活控制用戶的權(quán)限級別。

缺點(diǎn)：

• 增加復(fù)雜性：角色的臨時(shí)認(rèn)證通常涉及更多的設(shè)置和配置步驟，相比直接使用用戶賬號進(jìn)行認(rèn)證可能更為復(fù)雜。特別是對于初次接觸和不熟悉角色概念的人員來說，這可能需要額外的學(xué)習(xí)和配置成本。
• 可用性和延遲：由于臨時(shí)憑證的過期時(shí)間，用戶可能需要定期重新獲取憑證以維持訪問權(quán)限。這可能導(dǎo)致一些中斷或延遲，特別是在憑證過期前用戶未及時(shí)獲取新憑證的情況下。
• 授權(quán)復(fù)雜性：角色的臨時(shí)認(rèn)證可能需要更精細(xì)的權(quán)限設(shè)置和授權(quán)過程。您需要仔細(xì)定義和配置角色的權(quán)限范圍，以確保用戶具有足夠的權(quán)限執(zhí)行任務(wù)，同時(shí)避免過度授權(quán)導(dǎo)致安全風(fēng)險(xiǎn)。
• 平臺(tái)限制：并非所有平臺(tái)都支持角色的臨時(shí)認(rèn)證或具有相同的實(shí)現(xiàn)方式。在考慮使用角色進(jìn)行臨時(shí)認(rèn)證時(shí)，需要確保目標(biāo)平臺(tái)支持并提供適當(dāng)?shù)墓δ芎图蛇x項(xiàng)。

實(shí)施示例：

(1)例如 AWS：AWS Identity and Access Management (IAM) 提供了角色的臨時(shí)認(rèn)證功能。這使得我們可以方便地創(chuàng)建角色，并使用臨時(shí)憑證來獲取對 AWS 資源的操作權(quán)限，而無需使用長期憑證（如用戶名和密碼）。以下是一個(gè)具體的例子：假設(shè)我們在 AWS 上有一個(gè) EC2 實(shí)例，并且想要讓該實(shí)例能夠訪問 S3 存儲(chǔ)桶。以下是如何使用角色進(jìn)行臨時(shí)認(rèn)證的具體步驟：

通過使用角色的臨時(shí)認(rèn)證，可以避免在 EC2 實(shí)例上設(shè)置和管理長期憑證。相反，EC2 實(shí)例可以通過角色來獲取所需的臨時(shí)憑證，并且這些憑證具有定義的 S3 訪問權(quán)限。這提高了安全性，并簡化了憑證管理過程。

請注意，上述示例僅適用于AWS，并且是一個(gè)具體的用例。其他平臺(tái)和服務(wù)可能具有類似的功能和實(shí)現(xiàn)方式，但具體細(xì)節(jié)可能會(huì)有所不同。而且上述的步驟在實(shí)際的使用中是需要 as code 的，拒絕任何人為的步驟。

• 創(chuàng)建角色：使用 IAM 服務(wù)創(chuàng)建一個(gè)名為"EC2-S3-Access-Role"的角色。在角色策略配置中，為該角色授予適當(dāng)?shù)腟3訪問權(quán)限。
• 配置實(shí)例：將"EC2-S3-Access-Role"角色分配給 EC2 實(shí)例。可以在 EC2 實(shí)例的啟動(dòng)配置或?qū)嵗渲弥兄付ㄋ璧慕巧?/li>
• 獲取臨時(shí)憑證：在 EC2 實(shí)例中，使用實(shí)例配置角色（Instance Profile）來獲取臨時(shí)憑證。這些憑證將包含"EC2-S3-Access-Role"角色所授予的 S3 訪問權(quán)限。
• 訪問 S3 存儲(chǔ)桶：使用獲取的臨時(shí)憑證，EC2 實(shí)例現(xiàn)在可以通過 AWS SDK 或 AWS 命令行工具訪問指定的 S3 存儲(chǔ)桶，而無需使用用戶名和密碼。

(2)例如 Github：在 Github 中的組織中，我們可以創(chuàng)建團(tuán)隊(duì)，為團(tuán)隊(duì)分配權(quán)限和訪問控制。通過創(chuàng)建團(tuán)隊(duì)，可以將一組人員組織在一起，并為他們分配某個(gè)代碼倉庫的特定的權(quán)限角色，例如 Admin/Write/Read 等 role，分別對應(yīng)讀取或?qū)懭氲炔僮鞔a倉庫的權(quán)限。這樣，我們可以更容易地管理團(tuán)隊(duì)成員的訪問權(quán)限，而不是單獨(dú)為每個(gè)成員設(shè)置權(quán)限。

對于長期憑證，定期輪換密碼或訪問密鑰

長期憑證（如密碼、訪問密鑰、證書等）是指用于身份驗(yàn)證和授權(quán)的憑證，它們被分配給個(gè)人或應(yīng)用程序，以便它們可以訪問系統(tǒng)或服務(wù)。長期憑證容易被盜用或泄露，如果不及時(shí)輪換，可能會(huì)導(dǎo)致安全漏洞。定期輪換長期憑證是一種重要的安全管理措施，可以幫助組織降低風(fēng)險(xiǎn)，符合安全合規(guī)要求，防止不可撤銷的訪問權(quán)限，并提高安全意識(shí)。

優(yōu)點(diǎn)：

• 控制泄露影響：通過限制可用周期減少憑證泄漏產(chǎn)生的影響。
• 降低泄露范圍：可以確定使用方的使用狀態(tài)，清理未使用的憑證，降低泄漏的范圍。
• 符合標(biāo)準(zhǔn)：幫助系統(tǒng)通過 PCI-DSS 等強(qiáng)制標(biāo)準(zhǔn)。

缺點(diǎn)：

• 需要進(jìn)行額外的操作：進(jìn)行輪換時(shí)可能需要停止服務(wù)，對用戶會(huì)有一定影響。
• 溝通成本高：可能需要與多方進(jìn)行溝通，共同商定輪換時(shí)間，如有一方未能按照約定進(jìn)行輪換，仍然會(huì)對部分用戶造成影響。
• 產(chǎn)生意外影響：進(jìn)行輪換時(shí)可能會(huì)遇到意料之外的情況，如配置錯(cuò)誤導(dǎo)致服務(wù)不可用。
• 增加管理成本：如需要密碼管理器或是設(shè)備進(jìn)行存儲(chǔ)，需要配置額外的監(jiān)控系統(tǒng)對輪換時(shí)間進(jìn)行監(jiān)控。

實(shí)施示例：

(1)對需要輪換的憑證設(shè)置監(jiān)控或通知，務(wù)必確保監(jiān)控或通知系統(tǒng)的可用性。

• 對 HTTPS TLS 證書可以通過外部監(jiān)控系統(tǒng)對其過期時(shí)間進(jìn)行監(jiān)控，對于其他類型的憑證可以設(shè)置一個(gè)計(jì)劃任務(wù)，及時(shí)提醒更換。
• 定期測試告警系統(tǒng)的通知是否送達(dá)。

(2)對更換周期要仔細(xì)斟酌，沒有適合所有系統(tǒng)的最優(yōu)解。

(3)使用密鑰掃描工具對代碼庫進(jìn)行掃描，避免代碼中出現(xiàn)硬編碼的密鑰，例如：

• GitHub 可以在 Settings - Security - Code security and analysis 啟用 Secret scanning
• 使用 TruffleHog、git-secrets、GitGuardian 等工具將密鑰掃描集成在 CI/CD 中，可參考OWASP 的這一篇。

(4)定期檢查證書是否需要使用較新的 cipher，增強(qiáng)系統(tǒng)安全性。

(5)記錄和完善文檔

• 及時(shí)完善各類憑證生成及驗(yàn)證方法的文檔，確保新生成的憑證可以在系統(tǒng)中使用
• 對集成方進(jìn)行記錄，確保在更換時(shí)可以找到相應(yīng) Point Of Contact

最小化權(quán)限原則

最小化權(quán)限原則是指系統(tǒng)的每個(gè)程序或者用戶都應(yīng)該使用完成工作所需的最小權(quán)限工作。最小權(quán)限原則限制操作所需的權(quán)限，降低賬號或者系統(tǒng)在被惡意利用時(shí)造成的損失。因此在給賬號或者角色賦權(quán)時(shí)，盡可能只賦予操作所需的權(quán)限，應(yīng)為用戶提供履行其工作職責(zé)所需的最低訪問級別，而非隨意擴(kuò)大權(quán)限范圍，這有助于降低意外或故意濫用特權(quán)的風(fēng)險(xiǎn)。即使我們需要給一些臨時(shí)的操作賦權(quán)，也不要賦予不必要的額外權(quán)限，并在操作完成之后清理臨時(shí)權(quán)限。如有可能，我們也建議新建臨時(shí)賬號來完成此類操作，而非擴(kuò)大原有賬號的權(quán)限。

優(yōu)點(diǎn)：

• 減少安全漏洞的風(fēng)險(xiǎn)：在不存在提權(quán)漏洞情況下，攻擊者只能執(zhí)行對該用戶所授權(quán)的操作。
• 限制數(shù)據(jù)泄露的風(fēng)險(xiǎn)：同上，攻擊者只能訪問該用戶被允許的文件。
• 簡化權(quán)限管理：降低對權(quán)限管理的工作量，可以快速確定使用范圍。
• 便于審計(jì)：隨時(shí)吊銷清理不必要的權(quán)限，降低系統(tǒng)的攻擊面。

缺點(diǎn)：

• 增加管理的復(fù)雜性：即使是使用權(quán)限組的情況下，仍有可能會(huì)增加管理的復(fù)雜性，尤其是存在較多權(quán)限組時(shí)。
• 影響工作效率：在限制訪問的情況下，做一件復(fù)雜的事時(shí)可能需要反復(fù)切換賬號。
• 增加系統(tǒng)開發(fā)的成本：如果是正在開發(fā)中的系統(tǒng)，可能會(huì)增加系統(tǒng)開發(fā)的成本。

實(shí)施要點(diǎn)：

• 要權(quán)衡安全和效率的關(guān)系，對基礎(chǔ)權(quán)限應(yīng)主動(dòng)給予，其他權(quán)限應(yīng)評估后授予。
• 不給予太過寬泛的權(quán)限，即使是用于測試，以此避免濫用的可能性。例如：在使用 CI 部署 AWS EC2 實(shí)例時(shí)，不應(yīng)該為了方便而給予 ec2:* 這樣的權(quán)限，而是應(yīng)該仔細(xì)查看權(quán)限列表，只授予需要的最小權(quán)限列表。
• 應(yīng)定期審查和更新權(quán)限，及時(shí)收回不必要的權(quán)限，降低攻擊和濫用風(fēng)險(xiǎn)。
• 對于 Linux 中的程序，必要時(shí)可使用 AppArmor 或是 SELinux 增強(qiáng)其權(quán)限管理。

定期查看并移除未使用的用戶、角色、權(quán)限等憑證

我們建議定期去查看系統(tǒng)中是否有未被使用的憑證信息，如果發(fā)現(xiàn)要及時(shí)進(jìn)行清理或禁用，以防止不必要的訪問權(quán)限和潛在的安全風(fēng)險(xiǎn)，提高安全水平。

優(yōu)點(diǎn)：

• 降低憑證泄漏的影響：避免通過找回早期生成的憑證對系統(tǒng)進(jìn)行操作。
• 降低管理成本：對長期未使用的憑證進(jìn)行清理可以簡化系統(tǒng)的管理和審計(jì)過程。

減少混淆：可以直接專注于真正在使用中的用戶、角色和權(quán)限。

缺點(diǎn)：

• 有誤刪風(fēng)險(xiǎn)：維護(hù)的過程中有誤刪的可能，有一定造成業(yè)務(wù)系統(tǒng)中斷的風(fēng)險(xiǎn)。
• 增加工作量：需要定期檢查，有對用戶造成不便的可能，但對于多數(shù)系統(tǒng)來說仍然是推薦的做法。

實(shí)施要點(diǎn)：

• 及時(shí)對未使用的憑證進(jìn)行清理，以避免過度堆積造成審計(jì)負(fù)擔(dān)。
• 在未確定是否仍在使用的情況下不要激進(jìn)武斷地刪除憑證。
• 可以使用自動(dòng)化工具對憑證進(jìn)行掃描，對近期未使用的憑證/用戶進(jìn)行清理。例如：對于 AWS 可配置 AWS Config iam-user-unused-credentials-check 來輔助檢查。

分離開發(fā)、測試和生產(chǎn)環(huán)境權(quán)限

我們?nèi)粘４蟛糠值墓ぷ鲌鼍岸加卸鄠€(gè)環(huán)境，我們建議對于開發(fā)、測試和生產(chǎn)環(huán)境應(yīng)該分別有不同的權(quán)限管理策略，以確保每個(gè)環(huán)境都具有正確的訪問權(quán)限，并且不會(huì)影響其他環(huán)境的安全性。

優(yōu)點(diǎn)：

• 增強(qiáng)生產(chǎn)環(huán)境的安全性：對生產(chǎn)環(huán)境權(quán)限的嚴(yán)格控制，可以最大限度地確保生產(chǎn)環(huán)境的安全，從權(quán)限上防止誤操作導(dǎo)致臟數(shù)據(jù)、惡意刪庫等行為。
• 提升非生產(chǎn)環(huán)境的權(quán)限：不同的權(quán)限管理策略，可以最大化地給予開發(fā)人員和測試人員在開發(fā)、測試環(huán)境的權(quán)限。并且使得他們在不受到權(quán)限限制影響的同時(shí)，也不用擔(dān)心會(huì)影響到生產(chǎn)環(huán)境的安全。

缺點(diǎn)：

• 緊急情況時(shí)流程復(fù)雜：當(dāng)遇到特殊的線上問題且無法在其他環(huán)境復(fù)現(xiàn)時(shí)，如果此時(shí)沒有足夠的生產(chǎn)權(quán)限，則需要申請生產(chǎn)環(huán)境權(quán)限，流程審批復(fù)雜時(shí)會(huì)浪費(fèi)時(shí)間。

實(shí)施要點(diǎn)：

• 各個(gè)環(huán)境的權(quán)限應(yīng)該由專門團(tuán)隊(duì)來統(tǒng)一管理和分發(fā)
• 對申請人的權(quán)限進(jìn)行分發(fā)時(shí)需要經(jīng)過該項(xiàng)目團(tuán)隊(duì)負(fù)責(zé)人的同意
• 權(quán)限的創(chuàng)建要遵循權(quán)限最小化原則，比如讀寫權(quán)限分離。

實(shí)施示例：

以 AWS 為例，對于部署在 AWS 上的服務(wù)，我們建議：

(1)將開發(fā)，測試和生產(chǎn)環(huán)境賬號分開，部署在不同的 AWS Account 里，實(shí)現(xiàn)整個(gè)環(huán)境的隔離

(2)分別為用戶在不同環(huán)境創(chuàng)建不同權(quán)限的 IAM role，例如：

• Example_dev_admin
• Example_dev_readonly
• Example_prod_admin
• Example_prod_readonly

使用強(qiáng)密碼策略

我們強(qiáng)烈建議使用強(qiáng)密碼策略，一個(gè)安全的密碼應(yīng)該不少于12個(gè)字符，至少有三種不同的字符，如數(shù)字，特殊字符，大小寫字母。應(yīng)避免在密碼中包含個(gè)人信息，如出生日期或名字，寵物或樂隊(duì)。還要避免歌詞，伴侶和常用詞組等。并且我們建議不要使用重復(fù)密碼，盡可能在不同的系統(tǒng)中使用不同的密碼，并定期更換密碼。

優(yōu)點(diǎn)：

• 提高安全性：使用強(qiáng)密碼策略可以大大提高賬戶的安全性。強(qiáng)密碼通常更難以猜測、破解或猜測，因此更難被惡意用戶破解并獲取對賬戶的未授權(quán)訪問。
• 防止撞庫：在不同的系統(tǒng)中使用不同的密碼，防止其他系統(tǒng)密碼意外泄漏后被撞庫。
• 減少數(shù)據(jù)損失：如果密碼發(fā)生泄漏，定期更換密碼可以減少數(shù)據(jù)損失。
• 減少密碼泄露風(fēng)險(xiǎn)：使用強(qiáng)密碼策略可以減少密碼泄露的風(fēng)險(xiǎn)。強(qiáng)密碼難以通過常見的攻擊手段（如字典攻擊、暴力破解、社交工程等）破解，從而降低賬戶被黑客入侵的可能性。

缺點(diǎn)：

• 用戶體驗(yàn)低：使用強(qiáng)密碼策略可能會(huì)給用戶帶來不便。長、復(fù)雜的密碼可能難以記憶，并可能需要經(jīng)常更改密碼。這可能導(dǎo)致用戶重復(fù)使用密碼、寫下密碼或?qū)で笃渌话踩姆椒ā?/li>
• 易忘記密碼：由于密碼的復(fù)雜性，用戶可能更容易忘記密碼。這可能導(dǎo)致密碼重置的頻率增加，給用戶和支持團(tuán)隊(duì)帶來額外的負(fù)擔(dān)。
• 密碼管理挑戰(zhàn)：對于具有多個(gè)賬戶和復(fù)雜密碼要求的用戶來說，管理和記憶所有密碼可能成為挑戰(zhàn)。這可能導(dǎo)致用戶使用密碼管理器或其他自動(dòng)化工具，或者采用不安全的解決方案。

實(shí)施示例：

例如 AWS：可以在 AWS IAM 中設(shè)置如下的用戶密碼策略，任何用戶的密碼必須遵守設(shè)置的策略：

• 設(shè)置密碼最小長度，AWS 支持密碼長度設(shè)置在 6-128 范圍內(nèi)。
• 設(shè)置密碼強(qiáng)度，例如至少需要一個(gè)大寫字母、至少需要一個(gè)小寫字母、至少需要一個(gè)數(shù)字或者至少需要一個(gè)字符。
• 設(shè)置密碼過期時(shí)間，例如設(shè)置為 90 天。
• 設(shè)置密碼過期需要管理員重置。
• 防止密碼重復(fù)使用，例如不能將密碼設(shè)置為之前設(shè)置過的密碼。

使用多重驗(yàn)證(MFA)

多重驗(yàn)證(MFA)是一個(gè)額外的安全措施，要求用戶在被授予系統(tǒng)訪問權(quán)限之前提供多種形式的身份驗(yàn)證。這可能包括發(fā)送到手機(jī)或其他設(shè)備的密碼或代碼。如果對應(yīng)的系統(tǒng)支持多重驗(yàn)證，我們建議開啟使用多重驗(yàn)證功能。并且不要把密碼管理工具和MFA工具安裝在同一設(shè)備上。

優(yōu)點(diǎn)：

• 提供多層保障：可以提高賬戶的安全保障，如果密碼不小心泄漏，多重驗(yàn)證可以提供第二層保護(hù)。
• 賬戶被盜可能性最小化：由于 MFA 可能是面部識(shí)別、指紋或者一次性密碼，所以被盜取的可能性非常小。
• 防止賬戶劫持：多重驗(yàn)證可以有效防止惡意用戶劫持他人的賬戶。除了知道密碼外，攻擊者還需要訪問用戶所擁有的其他驗(yàn)證因素，才能成功冒充用戶。
• 合規(guī)性要求：在某些行業(yè)和法規(guī)中，使用多重驗(yàn)證可能是強(qiáng)制性的要求。例如，支付卡行業(yè)（PCI DSS）對進(jìn)行支付交易的賬戶要求啟用多重驗(yàn)證。

缺點(diǎn)：

• 用戶體驗(yàn)煩瑣：使用多重驗(yàn)證可能會(huì)增加用戶登錄過程的復(fù)雜性和時(shí)間。用戶需要提供額外的驗(yàn)證因素，并可能需要額外的設(shè)備或應(yīng)用程序來完成驗(yàn)證。
• 依賴額外設(shè)備：某些多重驗(yàn)證方法可能需要額外的硬件設(shè)備（如硬件令牌）或應(yīng)用程序（如身份驗(yàn)證器應(yīng)用程序）。用戶需要確保這些設(shè)備或應(yīng)用程序可靠，并妥善保管。
• 丟失或損壞的設(shè)備：如果用戶的多重驗(yàn)證設(shè)備丟失或損壞，他們可能會(huì)面臨賬戶被鎖定的風(fēng)險(xiǎn)。在這種情況下，恢復(fù)訪問賬戶可能需要額外的步驟和時(shí)間。

實(shí)施要點(diǎn)：

• 選擇適當(dāng)?shù)尿?yàn)證因素：確定適合我們當(dāng)前環(huán)境和用戶的驗(yàn)證因素類型。常見的驗(yàn)證因素包括密碼、手機(jī)驗(yàn)證碼、硬件令牌、身份驗(yàn)證器應(yīng)用程序（如Google Authenticator）和生物識(shí)別（如指紋或面部識(shí)別）。根據(jù)實(shí)際需求和安全要求，選擇一個(gè)或多個(gè)驗(yàn)證因素。推薦使用硬件密鑰增強(qiáng)安全性和易用性，盡量不使用短信驗(yàn)證方式。
• 啟用強(qiáng)制性多重驗(yàn)證：對于敏感賬戶和重要權(quán)限的用戶，應(yīng)強(qiáng)制啟用多重驗(yàn)證。確保所有用戶了解并遵守多重驗(yàn)證政策，以保護(hù)賬戶的安全。
• 必要情況下可以強(qiáng)制添加兩種及以上的多重驗(yàn)證

開啟審計(jì)日志

如果你的系統(tǒng)支持記錄審計(jì)日志，我們建議開啟審計(jì)日志并保存至少半年的記錄。審計(jì)日志本身是法律剛性需求，是安全合規(guī)性檢查的必備材料之一。

優(yōu)點(diǎn)：

• 安全監(jiān)控：審計(jì)日志提供了對環(huán)境活動(dòng)和操作的完整可見性，能夠監(jiān)控和檢測潛在的安全威脅、漏洞或異常行為。
• 審計(jì)和合規(guī)性：審計(jì)日志可以用于滿足合規(guī)性要求，并支持安全審計(jì)和調(diào)查。它們記錄了誰在何時(shí)進(jìn)行了什么操作，為審核和合規(guī)性證明提供了關(guān)鍵的依據(jù)。
• 故障排除和故障恢復(fù)：審計(jì)日志可以幫助我們進(jìn)行故障排除，追蹤問題的根源，并支持故障恢復(fù)過程。
• 調(diào)查和取證：審計(jì)日志可以用于調(diào)查安全事件、追蹤攻擊來源以及為法律或法規(guī)要求收集證據(jù)。
• 分析和洞察：審計(jì)日志提供了對環(huán)境活動(dòng)的可追溯記錄，可以用于分析和獲取有關(guān)資源使用、訪問模式和行為趨勢的洞察。

缺點(diǎn)：

• 存儲(chǔ)成本增加：啟用審計(jì)日志可能會(huì)增加存儲(chǔ)成本，尤其是在有大量活動(dòng)和長期保留需求的情況下。存儲(chǔ)和保留審計(jì)日志可能需要額外的資源和成本。
• 處理復(fù)雜性：審計(jì)日志可能會(huì)產(chǎn)生大量的事件和日志數(shù)據(jù)，需要適當(dāng)?shù)墓ぞ吆图夹g(shù)來處理和分析這些數(shù)據(jù)。處理大量的日志數(shù)據(jù)可能需要投入時(shí)間和資源。
• 隱私和合規(guī)性考慮：審計(jì)日志可能包含敏感信息，因此必須遵守適用的隱私和合規(guī)性要求，例如數(shù)據(jù)保護(hù)和數(shù)據(jù)保留政策。

實(shí)施要點(diǎn)：

• 選擇合適的審計(jì)日志工具：例如：在 AWS 上，可以使用 AWS CloudTrail 來記錄和監(jiān)控環(huán)境的活動(dòng)。確保正確配置和啟用 CloudTrail，并根據(jù)需求設(shè)置適當(dāng)?shù)娜罩颈Ａ羝谙藓痛鎯?chǔ)位置。
• 定義審計(jì)日志策略：制定和文檔化審計(jì)日志策略，明確記錄哪些活動(dòng)和事件應(yīng)該被審計(jì)。根據(jù)實(shí)際需求和合規(guī)性要求，確定需要記錄的資源類型、操作類型和級別。
• 審核訪問權(quán)限：審查和驗(yàn)證用戶和角色的訪問權(quán)限，確保只有授權(quán)的實(shí)體能夠訪問和修改審計(jì)日志。采用最小特權(quán)原則，僅授予必要的權(quán)限以防止?jié)撛诘臑E用。
• 配置日志存儲(chǔ)和保留期：確定審計(jì)日志的存儲(chǔ)位置和保留期。根據(jù)合規(guī)性要求和業(yè)務(wù)需求，選擇適當(dāng)?shù)拇鎯?chǔ)服務(wù)和設(shè)置合理的保留期限。
• 配置自動(dòng)化審計(jì)策略，實(shí)時(shí)監(jiān)控和警報(bào)：建立實(shí)時(shí)監(jiān)控和警報(bào)機(jī)制，以便對重要的活動(dòng)和事件及時(shí)做出響應(yīng)。例如使用 AWS CloudWatch、AWS EventBridge 或其他警報(bào)服務(wù)來監(jiān)控審計(jì)日志，檢測異?；蚩梢傻幕顒?dòng)。
• 日志分析和可視化：使用適當(dāng)?shù)娜罩痉治龉ぞ吆图夹g(shù)，對審計(jì)日志進(jìn)行分析、搜索和可視化。這有助于快速發(fā)現(xiàn)潛在的安全威脅、異常行為或合規(guī)性問題。
• 定期審查和檢查：定期審查審計(jì)日志，檢查活動(dòng)和事件的記錄，并及時(shí)調(diào)查任何異常或可疑的情況。根據(jù)需要，更新和改進(jìn)審計(jì)日志策略和設(shè)置。
• 合規(guī)性要求：根據(jù)適用的合規(guī)性要求（如 GDPR、HIPAA、PCI DSS 等），確保審計(jì)日志的實(shí)施符合相關(guān)標(biāo)準(zhǔn)和規(guī)定。
• 培訓(xùn)和意識(shí)：提供培訓(xùn)和意識(shí)活動(dòng)，確保相關(guān)人員了解審計(jì)日志的重要性、使用方法和最佳實(shí)踐。培養(yǎng)團(tuán)隊(duì)對審計(jì)日志的積極態(tài)度和有效利用。審計(jì)應(yīng)該由不同的人員執(zhí)行，以確保權(quán)限分配的公正性和準(zhǔn)確性。
• 持續(xù)改進(jìn)：根據(jù)實(shí)際情況和反饋，持續(xù)改進(jìn)審計(jì)日志實(shí)施。定期評估并更新審計(jì)日志策略、工具和流程，以適應(yīng)變化的需求和威脅。