enhance(docs):Add Security Best practice

Signed-off-by: leonrayang <chl696@sina.com>

docs-zh/source/maintenance/security_practice.md

@@ -0,0 +1,145 @@
+# 最佳安全实践
+## 身份验证
+### AK和SK
+AK（Access Key）和SK（Secret Key）是用于身份验证和访问控制的安全凭证，常用于云服务提供商和其他在线平台。AK是用户的访问密钥，类似于用户名，用于标识用户身份。SK是与AK关联的密钥，类似于密码，用于验证用户身份和生成数字签名以确保数据的安全性。在安全领域，正确管理和使用AK和SK非常重要。以下是一些关于AK和SK安全的最佳实践：
+1. 保密性：AK和SK应该被妥善保管，并仅在需要时向受信任的实体（如应用程序或服务）提供。不应将AK和SK存储在公开可访问的位置，如版本控制系统、公开的代码仓库或公开的文档中。
+2. 定期轮换：定期更换AK和SK是一种良好的安全实践，可以降低密钥被滥用的风险。推荐定期更换密钥，例如每隔几个月或根据安全政策和标准的要求。
+3. 权限控制：为每个AK和SK设置适当的权限和访问控制是至关重要的。仅授予所需的最小权限以执行特定任务，并定期审核和更新权限设置，以确保始终保持最小特权原则。
+4. 加密传输：在使用AK和SK进行身份验证时，应使用安全的传输协议（如HTTPS）来保护凭证的传输过程，防止被中间人攻击截获或篡改。
+5. 强密码策略：选择强密码并遵循密码策略是保护SK的重要措施。密码应具有足够的复杂性，包括大小写字母、数字和特殊字符，并避免使用容易猜测或常见的密码。
+
+综上所述，保护AK和SK的安全性对于保障系统和数据的安全至关重要。严格遵循安全最佳实践，合理管理和使用AK和SK，可以降低安全风险并确保身份验证和访问控制的有效性。
+### AuthNode验证模块
+* 需求：
+  对Master主节点或者其他流程访问重要接口增加鉴权机制，避免未认证客户端及内部节点加入到集群中，当重要信息的拉取时需要校验。
+
+* 原理：
+  Authnode 是为 CubeFS 提供通用认证和授权框架的安全节点。此外， Authnode 还充当对称密钥和非对称密钥的集中密钥存储。Authnode 采用并定制了基于票证的 Kerberos 认证思想。具体来说，当客户端节点（ Master 、 MetaNode 、 DataNode 或 client 节点）访问服务时，首先需要在 Authnode 中展示用于身份验证的共享密钥。如果认证成功， AuthNode 将专门为该服务颁发一个限时票证。出于授权的目的，功能嵌入到票证中，以指示谁可以在什么资源上做什么 。
+<div style="text-align:center;">
+  <img src="../pic/cfs-security-practice-authnode.png" alt="Image" style="width:800px; height:auto;">
+</div>
+
+
+* 启动
+在CubeFS中的配置步骤（可参考docker/run_docker4auth.sh）
+1. 超级管理员使用authnode的key，通过createKey API可以为各模块生成专属key，比如客户端是Ckey，以及master是Skey。同时AuthNode中会存储模块ID-Key的对应关系；
+2. 各模块配置ID及Key，启动服务。
+扩大接口验证范围
+Master接口涉及大量的卷维度和集群维度的运营管理，需要保护集群管理的安全，可以选择在Master启用配置“authenticate”，这样接口操作会到Authnode再次验证ckey的正确性。
+
+## 授权政策及管理
+### 权限分级
+权限分admin权限和普通用户权限，admin权限具备普通用户的管理权限，卷的维度管理操作权限，在系统中以owner字段展示
+普通用户权限，基于admin的授权固定的访问路径（可以是根目录）和操作权限（读、写），操作自己挂载目录及子目录下的文件或者目录
+
+从卷的维度，用户分为两种类型：只读用户和读写用户。只读用户只能读取文件或目录，无法修改它们。此外，还支持限制用户仅能访问特定子目录中的文件。在挂载后，CubeFS 支持使用 Linux 用户、组和其他权限限制进行权限检查的功能。例如，给定以下文件权限：-rwxr-xr-x 2 service service f1，只有 "service" 用户可以修改该文件，而其他非 root 用户只能读取它。
+
+用户管理：https://cubefs.io/zh/docs/master/tools/cfs-cli/user.html#%E8%8E%B7%E5%8F%96%E7%94%A8%E6%88%B7%E4%BF%A1%E6%81%AF
+### 权限管理
+创建申请走管控平台审批，可以收紧owner（admin）创建后的使用（有删除卷的权限），卷的admin账号由管控平台创建管理，基于命名规则自动生成，用一个否则不安全，普通账户返回给业务
+例如：
+对接中间件，授权一个普通账户给业务返回，由管控平台保存owner，删除需要同管控平台申请
+ladp+自动挂载
+<div style="text-align:center;">
+  <img src="../pic/cfs-security-practice-ldap.png" alt="Image" style="width:800px; height:auto;">
+</div>
+### ldap的作用
+1. 用户身份验证：LDAP可用于验证用户的身份。用户的用户名和密码可以存储在LDAP目录中，当用户尝试进行身份验证时，系统可以通过LDAP协议与LDAP服务器通信，验证用户提供的凭据是否与存储在目录中的凭据匹配。
+2. 单一登录（Single Sign-On）：LDAP可以用作单一登录系统的认证后端。单一登录系统允许用户使用一组凭据登录到多个关联应用程序，而不需要为每个应用程序单独进行身份验证。LDAP作为认证后端，可以集中管理用户凭据，实现用户在多个应用程序间的无缝登录体验。
+3. 用户授权和权限管理：LDAP目录可以存储用户组织结构、角色和权限信息。基于LDAP的认证和授权系统可以根据用户的身份和所属组织结构，授予用户适当的权限和访问权限。这样可以确保只有经过授权的用户可以访问敏感数据和资源，提高系统的安全性。
+4. 集中式用户管理：LDAP提供了一个集中式的用户管理平台。组织可以在LDAP目录中存储和管理用户信息，包括用户名、密码、电子邮件地址、电话号码等。通过LDAP，管理员可以轻松地添加、修改或删除用户信息，而不需要在每个应用程序中单独进行操作，提高了管理效率和一致性。
+### 自动挂载的优势
+AK和SK应该被妥善保管，并仅在需要时向受信任的实体（如应用程序或服务）提供。不应将AK和SK存储在公开可访问的位置，如版本控制系统、公开的代码仓库或公开的文档中。
+避免ak、sk等信息泄露，提高密钥的安全可用
+基于ip、用户做ldap验证，通过ldap做权限管理控制
+
+## 网关
+master ip不直接暴露，使用网关的域名方式，优势如下：
+方便master节点更换，避免客户端配置变更，正常情况下上线业务变更配置重启比较麻烦
+保障接口安全，域名开放必要的master接口，例如程序需要的分区信息等，但管理类接口不对外开放，保护了管理权限
+作为监控、告警、成功率统计等
+可增加缓存层
+
+## 流量控制
+### 卷维度流量QOS
+大集群多租户运营模式中可提升资源利用率，降低成本，但也给系统稳定性带来了挑战，例如某租户下的一个卷的请求突增，流量对整个存储系统造成冲击：
+不同卷的数据及元数据分区可能会放置在一台机器，甚至一个磁盘上，某个卷的过大的读写请求会影响到同节点节点和磁盘上的其它卷的访问。
+带宽打满会影响集群节点间内部通讯，进而影响集群管理节点对数据节点状态判断，触例如数据均衡等行为，进一步加剧整个集群的抖动。
+冲击集群上游交换机，不仅影响存储系统本身，还会影响同一交换机下其他非存储类系统。
+因此，流量QoS是系统稳定运营的重要保障手段。
+
+
+设计文档：https://mp.weixin.qq.com/s/ytBvK3MazOzm3uDtzRBwaw
+
+使用文档：https://cubefs.io/zh/docs/master/maintenance/admin-api/master/volume.html#%E6%B5%81%E6%8E%A7
+
+
+### master请求接口QOS限制
+Master的稳定性对于整个集群非常重要，所以为了防止意外（失败大量重试）或者恶意攻击，需要对Master的接口进行qps限流管理。
+Master的接口限流为qps限流（每秒接受多少个请求），对于没有设置限流的接口，不做任何限制。对于设置了限流的接口，有一个限流等待超时时间可以设置，防止雪崩效应。
+
+使用文档：https://cubefs.io/zh/docs/master/user-guide/qos.html
+
+## 对象服务安全相关特性
+### S3鉴权能力
+* 为了保障CubeFS中的数据以及请求过程的安全性，所有请求要么是签名认证的，要么是匿名授权的。CubeFS的签名能够从如下维度保护用户数据的安全：
+请求方身份认证
+* 请求签名要求您必须通过AK和Sk进行签名计算，服务端也能通过AK识别请求方的身份。
+### 数据防篡改
+* 为了防止数据传输过程中被篡改，将请求元素也参与到请求签名的计算中。当收到请求后，服务端会通过接收到的请求元素进行签名计算，如果请求元素出现篡改，那么两边的签名比较将无法通过。
+* ObjectNode支持V2、V4和STS三种兼容S3协议的签名算法，同时兼容Header、Query和Form三种子签名方式，能够保障用户请求过程中的数据安全性。
+
+### 权限管控
+* 权限管控是基于用户和资源的授权策略，对请求用户的行为进行访问控制，常用的应用场景有：对用户和 API 的组合控制、对客户端 IP、请求 Referer 等信息进行控制、内外网隔离访问控制等。
+* CubeFS 针对存储桶和对象的访问，主要提供了以下权限控制策略：Bucket Policy 和 ACL。在 CubeFS 的权限管控中，首先校验的是 Bucket Policy，只有 Bucket 没有设置 Policy 或者 Policy 中没有匹配到对应权限时，才会继续进行 ACL 校验。
+
+### WORM模式
+* 对象锁定（Object Lock）可以实现一次写入，多次读取 (WORM) 模式来存储对象。Object Lock可以帮助用户满足需要 WORM 存储的法规要求，也可以增加额外的保护来防止对象被更改和删除。
+为用户提供设置(取消)和获取Bucket对象锁定配置的接口。用户配置Bucket对象锁定后，所有上传的新对象都遵从此配置，存量对象不受影响。
+* 为用户提供通过HeadObject以及GetObject获取对象的保留周期、保留模式的功能。
+* 在对象锁定保护期内，对象不会被删除和覆盖。
+
+### S3API QoS
+为保证CubeFS服务的可用性和规避异常用户流量的影响，ObjectNode支持S3API级别下不同用户的并发/QPS/带宽维度的流控策略。
+
+## ACL IP黑名单
+* 加强端侧可控，为业务、运营管理者提供基于IP的可屏蔽策略。客户端挂载请求和已经挂载的客户端，所在IP加入黑名单后会无法继续服务。例如
+* 防止未经授权的访问：ACL IP黑名单可以用于阻止已知的恶意IP地址的访问，从而保护网络资源免受未经授权的访问或攻击。
+* 阻止恶意流量：阻止这些来源的恶意流量，例如分布式拒绝服务（DDoS）攻击、恶意扫描或爬虫等。
+
+具体使用方法：
+```
+./cfs-cli acl
+Manage cluster volumes acl black list
+Usage:
+  cfs-cli acl [command]
+
+Aliases:
+  acl, acl
+
+Available Commands:
+  add         add volume ip
+  check       check volume ip
+  del         del volume ip
+  list        list volume ip list
+```
+## 防火墙端口范围
+master、datanode、metanode、authnode、objectnode、lcnode等服务端都有监听端口范围
+只开放必要的端口，关闭不必要的端口。这可以通过防火墙规则或系统配置来实现。例如，如果您只需要通过SSH进行远程管理，您可以关闭其他不必要的远程管理端口，如Telnet。
+## 审计日志
+挂载点的操作审计流水，审计日志存放在客户端本地指定目录，方便接入第三方的日志采集平台。
+可以在客户端配置中开启或者关闭本地审计日志功能 Client 配置
+可以通过http发送命令到客户端主动开启或者关闭日志功能，不用重新挂载
+客户端审计日志记录在本地，日志文件超过200MB会进行滚动，滚动后的陈旧日志会在7天后进行删除。也就是审计日志默认保留7天的审计流水，每小时触发一次陈旧日志文件扫描删除
+
+客户端默认开始审计（3.3.1）开始，审计日志从客户端审计日志转为服务端日志，服务端审计可以设置是否开启，默认是关闭的
+## 删除保护 
+在卷维度下，设定一个文件或者目录创建后的禁止删除时间，这样文件或者目录，创建后在这个禁止时间内都不准许删除。
+用户可以通过cli工具设置删除锁定周期，并判断传入的参数值是否大于0，若大于0，则用该值更新卷的删除锁定周期。
+client会定期到master拉取卷信息并缓存，拉取完成之后，client才正式开启删除锁定功能。
+客户端执行删除之前会判断缓存的卷信息中的删除锁定周期是否为0，若不为零则说明已开启删除锁定功能，此时需要进行判断。若当前卷上设置的删除锁定周期小于当前时间和文件或目录创建时间的差值，则允许执行删除的后续逻辑。
+默认情况下，卷的删除锁定功能是关闭的，要打开该功能只需要在创卷或者更新卷的过程中指定删除锁定周期为一个正数即可。cli命令的使用：
+```
+创建卷：volume create [VOLUME NAME] --deleteLockTime=[VALUE]
+更新卷：volume update [VOLUME NAME] --deleteLockTime=[VALUE]
+```

docs-zh/source/sidebarConfig.js

@@ -61,6 +61,7 @@ module.exports = [
             'maintenance/zone.md',
             'maintenance/log.md',
             'maintenance/code.md',
+	        'maintenance/security_practice.md',
             {
                 text: '服务管理',
                 children: [

docs/source/maintenance/security_practice.md

@@ -0,0 +1,155 @@
+# CubeFS Best Security Practices
+## Authentication
+### AK and SK
+AK (Access Key) and SK (Secret Key) are secure credentials used for authentication and access control, commonly used in cloud service providers and other online platforms. AK is the user's access key, similar to a username, used to identify the user's identity. SK is the associated key with AK, similar to a password, used to verify the user's identity and generate digital signatures to ensure data security. Proper management and usage of AK and SK are crucial in the security domain. Here are some best practices for AK and SK security:
+1. Confidentiality: AK and SK should be securely stored and only provided to trusted entities (such as applications or services) when necessary. They should not be stored in publicly accessible locations, such as version control systems, public code repositories, or public documents.
+2. Regular Rotation: Regularly rotating AK and SK is a good security practice to mitigate the risk of key misuse. It is recommended to change keys periodically, such as every few months or as per security policies and standards requirements.
+3. Permission Control: Setting appropriate permissions and access controls for each AK and SK is vital. Only grant the minimum required privileges to perform specific tasks, and regularly review and update permission settings to ensure the principle of least privilege is always maintained.
+4. Encrypted Transmission: When using AK and SK for authentication, secure transmission protocols (such as HTTPS) should be employed to protect the credentials during the transmission process, preventing interception or tampering by man-in-the-middle attacks.
+5. Strong Password Policy: Selecting strong passwords and following password policies is an important measure to protect SK. Passwords should have sufficient complexity, including a combination of uppercase and lowercase letters, numbers, and special characters, while avoiding easily guessable or common passwords.
+
+In conclusion, ensuring the security of AK and SK is crucial for safeguarding the security of systems and data. By strictly adhering to security best practices and properly managing and using AK and SK, security risks can be mitigated, and the effectiveness of authentication and access control can be ensured.
+### AuthNode:Authentication Module
+* Requirements：
+Add authentication to the Master node or other important interfaces in the access process to prevent unauthenticated clients and internal nodes from joining the cluster. Verification is required when important information is pulled.
+
+* Principles：
+  Authnode is a secure node that provides a universal authentication and authorization framework for CubeFS. In addition, Authnode serves as a centralized key storage for both symmetric and asymmetric keys. Authnode adopts and customizes the ticket-based Kerberos authentication concept. Specifically, when a client node (Master, MetaNode, DataNode, or client node) accesses the service, it needs to present a shared key for authentication to Authnode. If the authentication is successful, Authnode issues a time-limited ticket specifically for that service. For authorization purposes, functionality is embedded in the ticket to indicate who can do what on which resources.
+<div style="text-align:center;">
+  <img src="../pic/cfs-security-practice-authnode.png" alt="Image" style="width:800px; height:auto;">
+</div>
+
+
+* Startup
+Configuration steps in CubeFS (refer to docker/run_docker4auth.sh)
+  * The super administrator uses the key of authnode and can generate exclusive keys for each module through the createKey API. For example, the client is Ckey and the master is Skey. At the same time, the corresponding relationship between module ID and Key will be stored in AuthNode;
+  * Configure ID and Key for each module and start the service.
+* Expand the scope of Master interface verification
+The Master interface requires a significant amount of operational management at both the volume and cluster levels. It is essential to ensure the security of cluster management. To achieve this, you can enable the "authenticate" configuration on the Master. This will require interface operations to undergo a secondary verification of the correctness  at Authnode. 
+
+## Authorization Policies and Management
+### Permission Levels
+* Permissions are divided into admin privileges and regular user privileges. Admin privileges include management privileges of regular users and operational privileges at the volume level, which are displayed in the system through the "owner" field.
+* Regular user privileges are based on admin authorization and have fixed access paths (such as the root directory) and operational permissions (read, write). Users can only operate on files or directories within their own mounted directory and its subdirectories.
+* From the perspective of volumes, users are classified into two types: read-only users and read-write users. Read-only users can only read files or directories and cannot modify them. Additionally, it is possible to restrict users to access only specific subdirectories. After mounting, CubeFS supports permission checks based on Linux user, group, and other permission restrictions. For example, given the following file permissions: -rwxr-xr-x 2 service service f1, only the "service" user can modify the file, while other non-root users can only read it.
+
+User managment：https://cubefs.io/docs/master/tools/cfs-cli/user.html
+### Permission Management
+The creation request goes through the governance platform for approval. After creation, the usage of the owner (admin) can be tightened, with the ability to delete volumes. The admin account for the volume is created and managed by the governance platform, automatically generated based on naming rules. Sharing a single admin account is otherwise insecure, so a regular account is provided to the business.
+
+For example:
+When integrating with middleware, a regular account is authorized and provided to the business. The governance platform retains the owner information, and any deletion requests need to be submitted through the governance platform for approval.
+
+## ladp+autoMount
+<div style="text-align:center;">
+  <img src="../pic/cfs-security-practice-ldap.png" alt="Image" style="width:800px; height:auto;">
+</div>
+
+### The role of LDAP
+* User Authentication: LDAP can be used to authenticate user identities. Usernames and passwords can be stored in an LDAP directory, and when a user attempts to authenticate, the system can communicate with the LDAP server via the LDAP protocol to verify if the credentials provided by the user match those stored in the directory.
+* Single Sign-On (SSO): LDAP can serve as an authentication backend for a Single Sign-On system. SSO allows users to log in to multiple associated applications using a single set of credentials, eliminating the need for separate authentication for each application. By using LDAP as the authentication backend, user credentials can be managed centrally, enabling a seamless login experience across multiple applications.
+* User Authorization and Permission Management: The LDAP directory can store user organizational structure, roles, and permission information. An LDAP-based authentication and authorization system can grant users appropriate permissions and access based on their identity and organizational structure. This ensures that only authorized users can access sensitive data and resources, enhancing system security.
+* Centralized User Management: LDAP provides a centralized user management platform. Organizations can store and manage user information, including usernames, passwords, email addresses, phone numbers, etc., in an LDAP directory. Through LDAP, administrators can easily add, modify, or delete user information without the need for individual operations in each application, improving management efficiency and consistency.
+### Advantages of automatic mounting
+* AK and SK should be properly safeguarded and only provided to trusted entities (such as applications or services) when necessary. AK and SK should not be stored in publicly accessible locations, such as version control systems, public code repositories, or public documents.
+* To prevent the leakage of AK, SK, and other sensitive information, it is important to enhance the security and availability of keys.
+* LDAP-based authentication can be implemented using IP and user-based verification. LDAP can also be utilized for controlling and managing permissions.
+
+## GateWay
+The master IP is not directly exposed, and a domain name approach is used through a gateway. The advantages are as follows:
+1. Easy master node replacement: Using a domain name approach avoids the need for client configuration changes. Under normal circumstances, it can be cumbersome to update business configurations and restart them.
+2. Ensuring interface security: The necessary master interfaces, such as partition information required by programs, can be exposed through the domain name. However, management interfaces are not exposed externally, protecting administrative privileges.
+3. Serving for monitoring, alerting, and success rate statistics: The domain name approach enables monitoring, alerting, and success rate statistics to be performed effectively.
+4. Adding a caching layer: Implementing a caching layer becomes feasible with the domain name approach.
+
+## Flow Control
+### Volume-level Read/Write Access Traffic QoS
+In the multi-tenant operation mode of large-scale clusters, resource utilization can be improved and costs can be reduced, but it also brings challenges to system stability. For example, when a large number of requests for a volume under a tenant suddenly increase, the traffic impacts the entire storage system:
+
+1. Different volumes' data and metadata partitions may be placed on the same machine or even the same disk. A large read/write request for a certain volume will affect the access of other volumes on the same node and disk.
+
+2. When the bandwidth is full, it will affect internal communication between cluster nodes, further affecting the judgment of the cluster management node on the status of data nodes, triggering behaviors such as data balancing, and further exacerbating the shaking of the entire cluster.
+
+3. Impacting the upstream switch of the cluster will not only affect the storage system itself but also affect other non-storage systems under the same switch.
+
+Therefore, traffic QoS is an important means of ensuring stable operation of the system.
+
+* Design document：```https://mp.weixin.qq.com/s/ytBvK3MazOzm3uDtzRBwaw```
+* User document：```https://cubefs.io/zh/docs/master/maintenance/admin-api/master/volume.html#%E6%B5%81%E6%8E%A7```
+
+
+### Master Request Interface QoS Limitation
+* The stability of the Master node is crucial for the entire cluster. To prevent accidents (such as excessive retries in case of failures) or malicious attacks, it is necessary to implement QPS (Queries Per Second) rate limiting management for the Master's interfaces
+* QPS rate limiting sets a limit on the number of requests the Master can accept per second. For interfaces without rate limiting set, no restrictions are applied. For interfaces with rate limiting configured, there is an option to set a timeout for rate limiting waits, preventing the occurrence of cascading failures.
+
+User document：https://cubefs.io/zh/docs/master/user-guide/qos.html
+
+## Object Service Security-Related Features
+### S3 Authentication Capability
+To ensure the security of data and request processes in CubeFS, all requests are either signed and authenticated or anonymously authorized. CubeFS's signature mechanism protects the security of user data in the following dimensions:
+
+1. Requester Identity Authentication: Requesters must authenticate their identity through signature calculations using Access Key (AK) and Secret Key (SK). The server can identify the requester's identity through the AK.
+
+2. Data Integrity: To prevent data tampering during transmission, the request elements are included in the signature calculation. Upon receiving a request, the server performs a signature calculation using the received request elements. If the request elements have been tampered with, the signature comparison between the client and server will not match.
+
+3. ObjectNode supports three compatible S3 protocol signature algorithms: V2, V4, and STS. It also supports three sub-signature methods: Header, Query, and Form, ensuring the data security of user requests throughout the process.
+
+### Permission Control
+* Permission control is an authorization strategy based on users and resources, which regulates access to user actions. Common application scenarios include controlling user and API combinations, controlling client IP addresses, request referers, and implementing internal and external network isolation access control.
+* CubeFS provides the following permission control strategies primarily for accessing storage buckets and objects: Bucket Policy and ACL. In CubeFS's permission control, the first validation performed is the Bucket Policy. Only when a bucket does not have a set policy or the policy does not match the corresponding permissions, will ACL validation be performed.
+
+### WORM Mode
+Object Lock enables the storage of objects in a Write Once, Read Many (WORM) mode. Object Lock allows users to comply with regulatory requirements for WORM storage and provides additional protection to prevent objects from being modified or deleted.
+
+* An interface is provided to users for setting (canceling) and retrieving the Bucket object lock configuration. Once the Bucket object lock is configured by the user, all newly uploaded objects will adhere to this configuration, while existing objects remain unaffected.
+* Users are provided with the functionality to retrieve the retention period and retention mode of objects through the HeadObject and GetObject methods.
+During the object lock protection period, objects cannot be deleted or overwritten.
+
+### S3API QoS
+To ensure the availability of CubeFS services and mitigate the impact of abnormal user traffic, ObjectNode supports flow control policies at the concurrency, QPS (Queries Per Second), and bandwidth dimensions for different users under the S3API level.
+
+## ACL IP BlackList
+* Strengthening client-side control, we provide IP-based blocking policies for business and operations managers. Once an IP address belonging to a client mounting requests or an already mounted client is added to the blacklist, it will no longer be able to access the service. For example:
+
+* Preventing unauthorized access: ACL IP blacklisting can be used to block access from known malicious IP addresses, thus protecting network resources from unauthorized access or attacks.
+* Blocking malicious traffic: It helps to block malicious traffic from these sources, such as distributed denial of service (DDoS) attacks, malicious scanning, or web crawling.
+
+ Usage Methods：
+```
+./cfs-cli acl
+Manage cluster volumes acl black list
+Usage:
+  cfs-cli acl [command]
+
+Aliases:
+  acl, acl
+
+Available Commands:
+  add         add volume ip
+  check       check volume ip
+  del         del volume ip
+  list        list volume ip list
+```
+## Firewall Port Range
+The master, datanode, metanode, authnode, objectnode, lcnode, and other server-side components have a range of listening ports. It is recommended to only open necessary ports and close unnecessary ones. This can be achieved through firewall rules or system configurations. For example, if you only need to remotely manage the system via SSH, you can close other unnecessary remote management ports such as Telnet.
+## Audit Log
+The operation audit trail of the mount point is stored in a locally specified directory on the client, making it convenient to integrate with third-party log collection platforms.
+
+* The local audit log feature can be enabled or disabled in the client configuration.
+* Clients can also receive commands via HTTP to actively enable or disable the log feature without the need for remounting.
+* The client audit logs are recorded locally, and when a log file exceeds 200MB, it is rolled over. The outdated logs after rolling over are deleted after 7 days. In other words, the audit logs are retained for 7 days by default, and outdated log files are scanned and deleted every hour.
+
+Starting from version 3.3.1, client-side auditing is enabled by default. However, instead of storing audit logs on the client, they are now stored on the server. Server-side auditing can be configured to enable or disable it, with the default setting being disabled.
+
+## Delete Protection.
+At the volume level, a prohibition period can be set for a file or directory after its creation, during which it is not allowed to be deleted. 
+
+Users can use the CLI tool to set the deletion lock period and check if the parameter value passed is greater than 0. If it is greater than 0, the deletion lock period of the volume is updated with that value.
+
+* The client periodically fetches volume information from the master and caches it. The deletion lock feature is only enabled on the client after the volume information is successfully fetched.
+* Before executing a deletion, the client checks if the deletion lock period in the cached volume information is non-zero, indicating that the deletion lock feature is enabled. In this case, further checks are performed. If the deletion lock period set on the current volume is less than the difference between the current time and the creation time of the file or directory, the deletion can proceed with the subsequent logic.
+* By default, the deletion lock feature is disabled for volumes. To enable this feature, it can be turned on during the volume creation or update process.
+```
+volume create：volume create [VOLUME NAME] --deleteLockTime=[VALUE]
+volume update：volume update [VOLUME NAME] --deleteLockTime=[VALUE]
+```

docs/source/sidebarConfig.js

@@ -61,6 +61,7 @@ module.exports = [
             'maintenance/zone.md',
             'maintenance/log.md',
             'maintenance/code.md',
+            'maintenance/security_practice.md',
             {
                 text: 'Service Management',
                 children: [
@@ -154,4 +155,4 @@ module.exports = [
             'faq/kafka.md',
         ]
     }
-]
+]