當(dāng)前位置：首頁 > 科技 > 軟件

DevOps優(yōu)秀實(shí)踐之用戶與權(quán)限

來源：責(zé)編：時間：2023-09-28 10:05:49 354觀看

導(dǎo)讀作者| 趙佩本系列內(nèi)容是我們在不同項目的維護(hù)過程中總結(jié)的關(guān)于 DevOps/SRE 方面的最佳實(shí)踐，我們將致力于在項目上盡最大的努力來推行這些最佳實(shí)踐。我們希望這些最佳實(shí)踐能對項目的穩(wěn)定運(yùn)營提供幫助，也希望剛接觸 DevOp

作者| 趙佩

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

用戶和權(quán)限管理對于維護(hù)一個安全可靠的基礎(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)險，減少人為錯誤，強(qiáng)制執(zhí)行安全控制，符合法規(guī)。

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

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

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

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

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

缺點(diǎn)：

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

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

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

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

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

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

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

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

缺點(diǎn)：

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

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

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

實(shí)施示例：

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

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

(2)以 Nexus 為例，在制品庫平臺上為 CI/CD 平臺的 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)限，疏忽和不慎的操作有可能帶來極大的損失。如果是在多人管理的情況下，也會增加賬號泄漏的風(fēng)險。同時，我們強(qiáng)烈建議對于特權(quán)賬號施行一切必要的安全管理，比如強(qiáng)密碼，開啟多重驗證，及時的操作審計等。

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

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

缺點(diǎn)：

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

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

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

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

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

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

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

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

使用角色而非用戶賬號

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

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

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

缺點(diǎn)：

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

實(shí)施示例：

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

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

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

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

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

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

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

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

實(shí)施示例：

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

對 HTTPS TLS 證書可以通過外部監(jiān)控系統(tǒng)對其過期時間進(jìn)行監(jiān)控，對于其他類型的憑證可以設(shè)置一個計劃任務(wù)，及時提醒更換。
定期測試告警系統(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)記錄和完善文檔

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

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

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

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

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

缺點(diǎn)：

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

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

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

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

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

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

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

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

缺點(diǎn)：

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

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

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

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

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

缺點(diǎn)：

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

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

各個環(huán)境的權(quán)限應(yīng)該由專門團(tuán)隊來統(tǒng)一管理和分發(fā)
對申請人的權(quán)限進(jìn)行分發(fā)時需要經(jīng)過該項目團(tuán)隊負(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)整個環(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)密碼策略，一個安全的密碼應(yīng)該不少于12個字符，至少有三種不同的字符，如數(shù)字，特殊字符，大小寫字母。應(yīng)避免在密碼中包含個人信息，如出生日期或名字，寵物或樂隊。還要避免歌詞，伴侶和常用詞組等。并且我們建議不要使用重復(fù)密碼，盡可能在不同的系統(tǒng)中使用不同的密碼，并定期更換密碼。

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

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

缺點(diǎn)：

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

實(shí)施示例：

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

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

使用多重驗證(MFA)

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

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

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

缺點(diǎn)：

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

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

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

開啟審計日志

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

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

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

缺點(diǎn)：

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

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

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

本文鏈接：http://m.www897cc.com/showinfo-26-11819-0.htmlDevOps優(yōu)秀實(shí)踐之用戶與權(quán)限

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： JDK為什么廢棄永久代，而引入元空間

下一篇：三個要點(diǎn)，掌握Spring Boot單元測試

標(biāo)簽：

熱門焦點(diǎn)

一加Ace2 Pro真機(jī)揭曉鈦空灰配色質(zhì)感拉滿

終于，在經(jīng)過了幾波預(yù)熱之后，一加Ace2 Pro的外觀真機(jī)圖在網(wǎng)上出現(xiàn)了。還是博主數(shù)碼閑聊站曝光的，這次的外觀設(shè)計還是延續(xù)了一加11的方案，只是細(xì)節(jié)上有了調(diào)整，例如新加入了鈦空灰
Raft算法：保障分布式系統(tǒng)共識的穩(wěn)健之道

1. 什么是Raft算法？Raft 是英文”Reliable、Replicated、Redundant、And Fault-Tolerant”（“可靠、可復(fù)制、可冗余、可容錯”）的首字母縮寫。Raft算法是一種用于在分布式系統(tǒng)
企業(yè)采用CRM系統(tǒng)的11個好處

客戶關(guān)系管理（CRM）軟件可以為企業(yè)提供很多的好處，從客戶保留到提高生產(chǎn)力?！　RM軟件用于企業(yè)收集客戶互動，以改善客戶體驗和滿意度?！　RM軟件市場規(guī)模如今超過580
梁柱接棒兩年，騰訊音樂闖出新路子

文丨田靜出品丨牛刀財經(jīng)（niudaocaijing）7月5日，企鵝FM發(fā)布官方公告稱由于業(yè)務(wù)調(diào)整，將于9月6日正式停止運(yùn)營，這意味著騰訊音樂長音頻業(yè)務(wù)走向消亡。騰訊在長音頻領(lǐng)域還在摸索。為
年輕人的“職場羞恥感”，無處不在

作者：馮曉亭陶淘李欣張琳馬舒葉來源：燃次元“人在職場，應(yīng)該選擇什么樣的著裝？”近日，在網(wǎng)絡(luò)上，一個與著裝相關(guān)的帖子引發(fā)關(guān)注，在該帖子里，一位在高級寫字樓亞洲金
華為Mate 60系列用上可變靈動島：正式版體驗將會更出色

這段時間以來，關(guān)于華為新旗艦的爆料日漸密集。據(jù)此前多方爆料，今年華為將開始恢復(fù)一年雙旗艦戰(zhàn)略，除上半年推出的P60系列外，往年下半年的Mate系列也將
AMD的AI芯片轉(zhuǎn)單給三星可能性不大與臺積電已合作至2nm制程

據(jù) DIGITIMES 消息，英偉達(dá) AI GPU 出貨逐季飆升，接下來 AMD MI 300 系列將在第 4 季底量產(chǎn)。而半導(dǎo)體業(yè)內(nèi)人士表示，近日傳出 AMD 的 AI 芯片將轉(zhuǎn)單給
與兆芯合作聯(lián)想推出全新旗艦版筆記本電腦開天N7系列

聯(lián)想與兆芯合作推出全新聯(lián)想旗艦版筆記本電腦開天 N7系列。這個系列采用兆芯KX-6640MA處理器平臺，KX-6640MA 處理器是采用了陸家嘴架構(gòu)，16nm 工藝，4 核 4 線
北京：科技教育體驗基地開始登記

　　北京“科技館之城”科技教育體驗基地登記和認(rèn)證工作日前啟動。首批北京科技教育體驗基地擬于2023年全國科普日期間掛牌，后續(xù)還將開展常態(tài)化登記?！　”本┛萍冀逃w驗基

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

DevOps優(yōu)秀實(shí)踐之用戶與權(quán)限

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

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

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

使用角色而非用戶賬號

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

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

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

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

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

缺點(diǎn)：

使用多重驗證(MFA)

開啟審計日志

一加Ace2 Pro真機(jī)揭曉鈦空灰配色質(zhì)感拉滿

Raft算法：保障分布式系統(tǒng)共識的穩(wěn)健之道

企業(yè)采用CRM系統(tǒng)的11個好處

梁柱接棒兩年，騰訊音樂闖出新路子

年輕人的“職場羞恥感”，無處不在

華為Mate 60系列用上可變靈動島：正式版體驗將會更出色

AMD的AI芯片轉(zhuǎn)單給三星可能性不大與臺積電已合作至2nm制程

與兆芯合作聯(lián)想推出全新旗艦版筆記本電腦開天N7系列

北京：科技教育體驗基地開始登記

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊

DevOps優(yōu)秀實(shí)踐之用戶與權(quán)限

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

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

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

使用角色而非用戶賬號

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

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

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

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

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

缺點(diǎn)：

使用多重驗證(MFA)

開啟審計日志

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊

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

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