Skip to content

Latest commit

 

History

History
147 lines (104 loc) · 9.61 KB

mitigations.md

File metadata and controls

147 lines (104 loc) · 9.61 KB

Mitigation Strategies Analysis for tikv/tikv

Mitigation Strategy: Enable TLS Encryption (TiKV-Specific)

Mitigation Strategy: Enable TLS Encryption for all TiKV communication channels.

  • Description:

    1. Generate Certificates: Use a trusted CA or a self-signed CA (dev/test only). Generate key pairs and certificates for each TiKV server instance.
    2. Configure TiKV: Modify the TiKV configuration file (tikv.toml or similar):
      • security.ca-path: Path to the CA certificate.
      • security.cert-path: Path to the TiKV server's certificate.
      • security.key-path: Path to the TiKV server's private key.
      • security.cipher-suites: List of strong, allowed cipher suites (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384). Crucially, this must be consistent across all TiKV, PD, and client configurations.
    3. Configure Inter-node Communication: Ensure the above security settings are applied consistently for both client-to-server and inter-node (TiKV-to-TiKV, TiKV-to-PD) communication. This often requires configuring how TiKV instances discover each other (e.g., through PD) to use TLS.
    4. Restart TiKV Instances: Restart all TiKV instances for the changes to take effect.
    5. Verify Connection: Use tools like openssl s_client (connecting to a TiKV port) or TiKV client with verbose logging to verify TLS is active and certificates are valid.

  • Threats Mitigated:

    • Data Exposure (High Severity): Prevents eavesdropping on data transmitted between TiKV nodes and between clients and TiKV.
    • Man-in-the-Middle (MitM) Attacks (High Severity): Prevents attackers from intercepting/modifying data in transit between TiKV nodes or between clients and TiKV.
    • Unauthorized Access (Medium Severity): Makes unauthorized connections more difficult (especially with mTLS).

  • Impact:

    • Data Exposure: Risk significantly reduced (almost eliminated with proper configuration).
    • MitM Attacks: Risk significantly reduced (almost eliminated with proper configuration).
    • Unauthorized Access: Risk reduced, further mitigated by mTLS.

  • Currently Implemented:

    • Basic TLS (server-side only) is configured for TiKV inter-node communication.

  • Missing Implementation:

    • Cipher suite configuration is not explicitly defined, relying on defaults.
    • TLS is not enforced for all internal communication; some diagnostic tools still use unencrypted connections.

Mitigation Strategy: Implement Mutual TLS (mTLS) (TiKV-Specific)

Mitigation Strategy: Implement Mutual TLS (mTLS) for TiKV client-server and inter-component authentication.

  • Description:

    1. Generate Client Certificates: Generate key pairs and certificates for each client that will connect to TiKV.
    2. Configure TiKV for Client Authentication: In the TiKV configuration file (tikv.toml), add:
      • security.verify-client-cert: Set to true to require client certificates.
      • security.client-ca-path: Path to the CA certificate used to verify client certificates.
    3. Configure Inter-node mTLS: Ensure that TiKV-to-TiKV and TiKV-to-PD communication also uses mTLS. This requires configuring the discovery mechanism (usually PD) to support and enforce mTLS. This is often the most complex part.
    4. Restart and Verify: Restart all TiKV instances and verify that clients without valid certificates are rejected, and that inter-node communication is also using mTLS.

  • Threats Mitigated:

    • Unauthorized Access (High Severity): Prevents unauthorized clients from connecting to TiKV, even with network access.
    • Spoofing Attacks (Medium Severity): Makes it harder to impersonate legitimate clients or TiKV nodes.

  • Impact:

    • Unauthorized Access: Risk significantly reduced (almost eliminated with proper configuration and key management).
    • Spoofing Attacks: Risk significantly reduced.

  • Currently Implemented:

    • Not implemented.

  • Missing Implementation:

    • mTLS is not configured on TiKV for either client connections or inter-node communication.

Mitigation Strategy: Connection Limits (TiKV Configuration)

Mitigation Strategy: Configure TiKV's max-connections setting appropriately.

  • Description:

    1. Assess Capacity: Determine the maximum number of concurrent connections your TiKV instances can handle based on hardware resources (CPU, memory, network bandwidth) and expected workload.
    2. Configure max-connections: In the TiKV configuration file (tikv.toml), set the server.max-connections parameter to a reasonable value. This is a global limit for each TiKV instance.
    3. Monitor and Tune: Monitor connection counts and system performance. Adjust max-connections as needed.

  • Threats Mitigated:

    • Denial of Service (DoS) (Medium Severity): Limits the total number of concurrent connections, preventing connection exhaustion. This is a basic, but important, defense.

  • Impact:

    • DoS: Risk partially reduced. It prevents one type of DoS, but other DoS attacks are still possible.

  • Currently Implemented:

    • max-connections is set to a default value.

  • Missing Implementation:

    • The value has not been tuned based on the specific hardware and workload.

Mitigation Strategy: Stay Updated (TiKV)

Mitigation Strategy: Keep TiKV up-to-date with the latest stable releases.

  • Description:

    1. Monitor Release Notes: Regularly check the TiKV release notes on GitHub for security patches and bug fixes.
    2. Test Updates: Before deploying updates to production, thoroughly test them in a staging environment that mirrors production as closely as possible.
    3. Rollback Plan: Have a documented rollback plan in case an update causes problems.
    4. Update Procedure: Follow the official TiKV upgrade documentation carefully.

  • Threats Mitigated:

    • Known Vulnerabilities (Variable Severity): Patches address known security vulnerabilities in TiKV itself.
    • Bugs (Variable Severity): Updates often include bug fixes that can improve stability and prevent data corruption specific to TiKV's internal operations.

  • Impact:

    • Known Vulnerabilities/Bugs: Risk reduced, depending on the severity of the patched issues.

  • Currently Implemented:

    • The project aims to stay on the latest stable releases, but updates are not always applied immediately.

  • Missing Implementation:

    • A formal process for testing and deploying TiKV updates is not in place.

Mitigation Strategy: Replication Factor (TiKV Configuration)

Mitigation Strategy: Ensure an appropriate replication factor is configured for the TiKV cluster.

  • Description:

    1. Understand Requirements: Determine the level of data redundancy and fault tolerance needed. A replication factor of 3 is generally recommended for production environments.
    2. Configure max-replicas: In the PD configuration file (which controls TiKV's replication), set the replication.max-replicas parameter to the desired value (e.g., 3). This setting dictates how many copies of each data region TiKV will maintain.
    3. Monitor Region Health: Use TiKV's monitoring tools (or PD's dashboard) to ensure that all regions have the expected number of replicas and that they are healthy.

  • Threats Mitigated:

    • Data Loss (High Severity): Provides redundancy in case of node failures. With a replication factor of 3, the cluster can tolerate the loss of one or two nodes without data loss.
    • Data Corruption (Medium Severity): Helps mitigate data corruption on a single node, as the healthy replicas can be used to recover the data.

  • Impact:

    • Data Loss: Risk significantly reduced.
    • Data Corruption: Risk reduced.

  • Currently Implemented:

    • max-replicas is set to 3.

  • Missing Implementation:

    • No specific monitoring alerts are configured for region health issues related to replication.

Mitigation Strategy: Checksum Verification (TiKV Configuration - Usually Default)

Mitigation Strategy: Ensure checksum verification is enabled in TiKV (usually on by default).

  • Description:

    1. Verify Configuration: Check the TiKV configuration file (tikv.toml) for settings related to checksums (e.g., storage.enable-ttl-check, raftstore.check-leader-lease). While usually enabled by default, it's crucial to confirm.
    2. Monitor Logs: Monitor TiKV logs for any checksum errors. These errors could indicate hardware problems, data corruption, or other issues.

  • Threats Mitigated:

    • Data Corruption (Medium Severity): Detects data corruption caused by hardware failures, software bugs, or other issues.

  • Impact:

    • Data Corruption: Risk of undetected data corruption is reduced. Checksums provide early warning.

  • Currently Implemented:

    • Checksum verification is enabled by default.

  • Missing Implementation:

    • No specific monitoring or alerting is configured to proactively detect checksum errors reported in logs.