當前位置：首頁 > 科技 > 軟件

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

來源：責編：時間：2023-09-28 10:05:49 267觀看

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

作者| 趙佩

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

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

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

給每個用戶建立獨立的賬號

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

優(yōu)點：

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

缺點：

增加管理成本：為每個用戶分配獨立賬號增加了管理復雜性

實施要點：

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

給每個服務建立專用的賬號

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

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

優(yōu)點：

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

缺點：

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

實施要點：

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

實施示例：

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

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

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

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

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

優(yōu)點：

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

缺點：

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

實施要點：

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

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

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

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

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

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

使用角色而非用戶賬號

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

優(yōu)點：

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

缺點：

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

實施示例：

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

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

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

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

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

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

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

優(yōu)點：

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

缺點：

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

實施示例：

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

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

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

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

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

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

(5)記錄和完善文檔

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

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

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

優(yōu)點：

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

缺點：

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

實施要點：

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

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

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

優(yōu)點：

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

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

缺點：

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

實施要點：

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

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

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

優(yōu)點：

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

缺點：

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

實施要點：

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

實施示例：

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

(1)將開發(fā)，測試和生產(chǎn)環(huán)境賬號分開，部署在不同的 AWS Account 里，實現(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

使用強密碼策略

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

優(yōu)點：

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

缺點：

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

實施示例：

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

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

使用多重驗證(MFA)

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

優(yōu)點：

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

缺點：

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

實施要點：

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

開啟審計日志

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

優(yōu)點：

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

缺點：

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

實施要點：

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

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

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

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

下一篇：三個要點，掌握Spring Boot單元測試

標簽：

熱門焦點

對標蘋果的靈動島華為帶來實況窗功能

繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據(jù)今天鴻蒙OS 4.0的現(xiàn)場演示顯示，華為的實況窗可以更高效的展現(xiàn)出實時通知，比如鎖屏上就能看到外賣、打車、銀行
小米平板5 Pro 12.4簡評：多專多能兼顧影音娛樂的大屏利器

疫情帶來了網(wǎng)課，網(wǎng)課盤活了安卓平板，安卓平板市場雖然中途停滯了幾年，但好的一點就是停滯的這幾年行業(yè)又有了新的發(fā)展方向，例如超窄邊框、高刷新率、多攝鏡頭組合等，這就讓安卓
三言兩語說透設計模式的藝術(shù)-簡單工廠模式

一、寫在前面工廠模式是最常見的一種創(chuàng)建型設計模式，通常說的工廠模式指的是工廠方法模式，是使用頻率最高的工廠模式。簡單工廠模式又稱為靜態(tài)工廠方法模式，不屬于GoF 23種設計
微信語音大揭秘：為什么禁止轉(zhuǎn)發(fā)？

大家好，我是你們的小米。今天，我要和大家聊一個有趣的話題：為什么微信語音不可以轉(zhuǎn)發(fā)？這是一個我們經(jīng)常在日常使用中遇到的問題，也是一個讓很多人好奇的問題。讓我們一起來揭開這
.NET 程序的 GDI 句柄泄露的再反思

一、背景1. 講故事上個月我寫過一篇如何洞察 C# 程序的 GDI 句柄泄露文章，當時用的是 GDIView + WinDbg 把問題搞定，前者用來定位泄露資源，后者用來定位泄露代碼，后面有朋友反
大廠卷向扁平化

來源：新熵作者丨南枝編輯丨月見大廠職級不香了。俗話說，兵無常勢，水無常形，互聯(lián)網(wǎng)企業(yè)調(diào)整職級體系并不稀奇。7月13日，淘寶天貓集團啟動了近年來最大的人力制度改革，目前已形成一
iQOO 11S評測：行業(yè)唯一的200W標準版旗艦

【Techweb評測】去年底，iQOO推出了“電競旗艦”iQOO 11系列，作為一款性能強機，該機不僅全球首發(fā)2K 144Hz E6全感屏，搭載了第二代驍龍8平臺及144Hz電競
iQOO Neo8 Pro搶先上架：首發(fā)天璣9200+ 安卓性能之王

經(jīng)過了一段時間的密集爆料，昨日iQOO官方如期對外宣布：將于5月23日推出全新的iQOO Neo8系列新品，官方稱這是一款擁有旗艦級性能調(diào)校的作品。隨著發(fā)布時
OPPO K11搭載長壽版100W超級閃充：26分鐘充滿100%

據(jù)此前官方宣布，OPPO將于7月25日也就是今天下午14:30舉辦新品發(fā)布會，屆時全新的OPPO K11將正式與大家見面，將主打旗艦影像，和同檔位競品相比，其最大的賣

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

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

給每個用戶建立獨立的賬號

給每個服務建立專用的賬號

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

使用角色而非用戶賬號

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

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

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

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

使用強密碼策略

缺點：

使用多重驗證(MFA)

開啟審計日志

對標蘋果的靈動島華為帶來實況窗功能

小米平板5 Pro 12.4簡評：多專多能兼顧影音娛樂的大屏利器

三言兩語說透設計模式的藝術(shù)-簡單工廠模式

微信語音大揭秘：為什么禁止轉(zhuǎn)發(fā)？

.NET 程序的 GDI 句柄泄露的再反思

大廠卷向扁平化

iQOO 11S評測：行業(yè)唯一的200W標準版旗艦

iQOO Neo8 Pro搶先上架：首發(fā)天璣9200+ 安卓性能之王

OPPO K11搭載長壽版100W超級閃充：26分鐘充滿100%

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊