Security Management Overview
Security Management Overview
TimechoDB provides security management features for accounts, permissions, connections, communication, storage, and auditing. Select and combine these features according to your actual use case.
Some security features are available only in TimechoDB. Before configuring a feature, review its documentation for applicable versions and licensing requirements.
1. Feature Guide
| Feature | Primary purpose | More information |
|---|---|---|
| Authority Management | Manage users, roles, global privileges, and data access privileges | Before V2.0.7; From V2.0.7 |
| Separation of Powers | Assign system management, security management, and audit management privileges to independent administrators | Separation of Powers |
| Account Security | Configure password policies, login failure lockout, connection quotas, and inactive connection removal | Account Security |
| Allowlist / Blocklist | Allow or deny connections according to client IP addresses | Allowlist / Blocklist |
| Communication Encryption | Use TLS or GM TLCP to protect data transmitted between clients and nodes | Communication Encryption |
| Storage Encryption | Encrypt configuration files, permission files, and TsFile data files | Storage Encryption |
| Security Audit | Record and query security events such as database operations, authorization results, and slow operations | Security Audit |
2. Choosing Features by Scenario
2.1 Control User Operation Privileges
Use Authority Management to create users and roles, then grant the privileges required for business operations. If different people need to manage system operations, user authorization, and security auditing separately, enable Separation of Powers.
2.2 Strengthen Login and Connection Security
Use Account Security to configure password requirements, password validity, login failure lockout, per-user connection limits, and idle session timeouts. Use Allowlist / Blocklist to restrict the client addresses allowed to access the database.
2.3 Protect Data in Transit and at Rest
Use Communication Encryption to protect data transmitted between clients and servers, and between cluster nodes. To use TLCP 1.1, the server and relevant Java clients must use a TLCP-enabled Kona JDK and be configured with compliant SM2 dual certificates. Use Storage Encryption to protect configuration files, permission files, and TsFile data files. Before enabling storage encryption, confirm your backup and recovery procedure and securely retain the data encryption password.
2.4 Trace Security Events
Use Security Audit to record database operations, logins and logouts, authorization results, and slow operations. After Separation of Powers is enabled, audit rules and audit logs are managed by the audit administrator.
3. Notes
- Separation of Powers cannot be disabled after it is enabled, and the original root user can no longer log in immediately.
- After communication encryption is enabled, clients must also enable communication encryption and configure a protocol and TrustStore compatible with the server; otherwise, they cannot connect to the corresponding port.
- After configuration file encryption is enabled, the original plaintext configuration files are deleted. Encrypted files cannot be viewed or decrypted directly. Use
SET CONFIGURATIONfor subsequent configuration changes. - After TsFile data encryption is enabled, each node startup must provide the
user_encrypt_tokenused when encryption was first enabled. If this token is lost, the node cannot read existing encrypted data.