作者| 趙佩

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

用戶和權限管理對于維護一個安全可靠的基礎設施和應用資源至關重要。在當今快節奏和協作的開發環境中，確保合適的人員擁有系統、資源和數據的適當訪問權限非常重要。通過實施用戶與權限管理實踐，組織可以降低未經授權訪問的風險，減少人為錯誤，強制執行安全控制，符合法規。

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

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

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

優點：

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

缺點：

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

實施要點：

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

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

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

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

優點：

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

缺點：

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

實施要點：

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

實施示例：

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

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

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

減少使用特權(root)賬號

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

優點：

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

缺點：

• 降低工作效率：某些工作若需要特殊權限，申請特權賬號會影響員工的工作效率
• 服務可能會產生異常：一些特殊服務需要特權賬號，普通用戶賬號可能會導致系統或應用程序出現故障或不可用

實施要點：

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

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

(2)限制應用程序的權限

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

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

(4)加強對特權賬號的審計和監管

使用角色而非用戶賬號

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

優點：

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

缺點：

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

實施示例：

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

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

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

• 創建角色：使用 IAM 服務創建一個名為"EC2-S3-Access-Role"的角色。在角色策略配置中，為該角色授予適當的S3訪問權限。
• 配置實例：將"EC2-S3-Access-Role"角色分配給 EC2 實例。可以在 EC2 實例的啟動配置或實例配置中指定所需的角色。
• 獲取臨時憑證：在 EC2 實例中，使用實例配置角色（Instance Profile）來獲取臨時憑證。這些憑證將包含"EC2-S3-Access-Role"角色所授予的 S3 訪問權限。
• 訪問 S3 存儲桶：使用獲取的臨時憑證，EC2 實例現在可以通過 AWS SDK 或 AWS 命令行工具訪問指定的 S3 存儲桶，而無需使用用戶名和密碼。

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

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

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

優點：

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

缺點：

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

實施示例：

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

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

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

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

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

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

(5)記錄和完善文檔

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

最小化權限原則

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

優點：

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

缺點：

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

實施要點：

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

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

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

優點：

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

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

缺點：

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

實施要點：

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

分離開發、測試和生產環境權限

我們日常大部分的工作場景都有多個環境，我們建議對于開發、測試和生產環境應該分別有不同的權限管理策略，以確保每個環境都具有正確的訪問權限，并且不會影響其他環境的安全性。

優點：

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

缺點：

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

實施要點：

• 各個環境的權限應該由專門團隊來統一管理和分發
• 對申請人的權限進行分發時需要經過該項目團隊負責人的同意
• 權限的創建要遵循權限最小化原則，比如讀寫權限分離。

實施示例：

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

(1)將開發，測試和生產環境賬號分開，部署在不同的 AWS Account 里，實現整個環境的隔離

(2)分別為用戶在不同環境創建不同權限的 IAM role，例如：

• Example_dev_admin
• Example_dev_readonly
• Example_prod_admin
• Example_prod_readonly

使用強密碼策略

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

優點：

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

缺點：

• 用戶體驗低：使用強密碼策略可能會給用戶帶來不便。長、復雜的密碼可能難以記憶，并可能需要經常更改密碼。這可能導致用戶重復使用密碼、寫下密碼或尋求其他不安全的方法。
• 易忘記密碼：由于密碼的復雜性，用戶可能更容易忘記密碼。這可能導致密碼重置的頻率增加，給用戶和支持團隊帶來額外的負擔。
• 密碼管理挑戰：對于具有多個賬戶和復雜密碼要求的用戶來說，管理和記憶所有密碼可能成為挑戰。這可能導致用戶使用密碼管理器或其他自動化工具，或者采用不安全的解決方案。

實施示例：

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

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

使用多重驗證(MFA)

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

優點：

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

缺點：

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

實施要點：

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

開啟審計日志

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

優點：

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

缺點：

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

實施要點：

• 選擇合適的審計日志工具：例如：在 AWS 上，可以使用 AWS CloudTrail 來記錄和監控環境的活動。確保正確配置和啟用 CloudTrail，并根據需求設置適當的日志保留期限和存儲位置。
• 定義審計日志策略：制定和文檔化審計日志策略，明確記錄哪些活動和事件應該被審計。根據實際需求和合規性要求，確定需要記錄的資源類型、操作類型和級別。
• 審核訪問權限：審查和驗證用戶和角色的訪問權限，確保只有授權的實體能夠訪問和修改審計日志。采用最小特權原則，僅授予必要的權限以防止潛在的濫用。
• 配置日志存儲和保留期：確定審計日志的存儲位置和保留期。根據合規性要求和業務需求，選擇適當的存儲服務和設置合理的保留期限。
• 配置自動化審計策略，實時監控和警報：建立實時監控和警報機制，以便對重要的活動和事件及時做出響應。例如使用 AWS CloudWatch、AWS EventBridge 或其他警報服務來監控審計日志，檢測異常或可疑的活動。
• 日志分析和可視化：使用適當的日志分析工具和技術，對審計日志進行分析、搜索和可視化。這有助于快速發現潛在的安全威脅、異常行為或合規性問題。
• 定期審查和檢查：定期審查審計日志，檢查活動和事件的記錄，并及時調查任何異常或可疑的情況。根據需要，更新和改進審計日志策略和設置。
• 合規性要求：根據適用的合規性要求（如 GDPR、HIPAA、PCI DSS 等），確保審計日志的實施符合相關標準和規定。
• 培訓和意識：提供培訓和意識活動，確保相關人員了解審計日志的重要性、使用方法和最佳實踐。培養團隊對審計日志的積極態度和有效利用。審計應該由不同的人員執行，以確保權限分配的公正性和準確性。
• 持續改進：根據實際情況和反饋，持續改進審計日志實施。定期評估并更新審計日志策略、工具和流程，以適應變化的需求和威脅。