【实战ES】实战 Elasticsearch：快速上手与深度实践-6.2.2GDPR数据脱敏处理

👉 点击关注不迷路
👉 点击关注不迷路
👉 点击关注不迷路

6.2.2 GDPR数据脱敏处理深度实践指南

• GDPR数据脱敏在Elasticsearch中的全流程处理

1. GDPR核心要求映射

1.1 关键条款与技术要求

1.2 数据类型与脱敏策略

• 敏感级别
  • 1. 核心分类对比

• Luhn算法
  • Luhn 算法（又称模数 10 算法）是一种验证身份识别码（如信用卡号、IMEI、社保号等）有效性的校验方法。
  • 关键应用场景
    • 支付数据预处理：防止无效卡号被存储
    • 日志审计增强：识别潜在的卡号伪造尝试
  • 算法步骤如下：

• 示例计算
  • 以信用卡号 49927398716 为例

原卡号：4 9 9 2 7 3 9 8 7 1 6
反转后：6 1 7 8 9 3 7 2 9 9 4
处理奇数位（第2、4、6、8、10位）：
  1 → 2 → 2
  8 → 16 → 7（16-9）
  3 → 6
  2 → 4
  9 → 18 → 9
总和 = 6 + 2 + 7 + 7 + 6 + 3 + 7 + 4 + 9 + 9 + 4 = 67
67 % 10 = 7 → 无效卡号（正确卡号应为 `49927398715`，总和60）

2. 全链路脱敏配置

2.1 动态脱敏管道

// 向 Elasticsearch 发送 PUT 请求，用于创建一个名为 gdpr_masking 的数据摄取管道
PUT _ingest/pipeline/gdpr_masking
{
    // 定义管道中的处理器列表，每个处理器按顺序对数据进行处理
    "processors": [
        {
            // 使用 fingerprint 处理器对指定字段进行哈希处理，以实现数据脱敏
            "fingerprint": {
                // 指定要进行哈希处理的字段为 id_number，通常用于处理敏感的身份标识数据
                "fields": ["id_number"],
                // 指定使用的哈希算法为 SHA - 256，这是一种安全的哈希算法
                "method": "SHA-256",
                // 为哈希过程添加盐值，增强哈希结果的安全性，防止通过彩虹表等方式破解
                "salt": "gdpr_salt_2023",
                // 指定将哈希结果存储到的目标字段为 id_hash
                "target_field": "id_hash"
            }
        },
        {
            // 使用 redact 处理器对指定字段进行正则表达式匹配和替换，实现对敏感信息的部分隐藏
            "redact": {
                // 指定要进行处理的字段为 email，用于处理电子邮件地址这种敏感信息
                "field": "email",
                // 定义正则表达式模式，用于匹配电子邮件地址。该模式匹配邮箱地址的用户名部分，保留前 3 个字符，其余用星号替换
                "patterns": ["\\b([A-Za-z0-9_]{3})[A-Za-z0-9_]+@([A-Za-z0-9_]+\\.)+[A-Za-z]{2,4}\\b"],
                // 定义替换规则，将匹配到的部分替换为 $1***@$2***，其中 $1 代表第一个捕获组（即用户名的前 3 个字符），$2 代表域名部分
                "replacement": "$1***@$2***"
            }
        },
        {
            // 使用 mask 处理器对指定字段的部分内容进行掩码处理，以保护敏感信息
            "mask": {
                // 指定要进行处理的字段为 phone，用于处理电话号码这种敏感信息
                "field": "phone",
                // 指定从电话号码的第 3 个字符开始进行掩码处理
                "start": 3,
                // 指定掩码处理到电话号码的第 7 个字符结束
                "end": 7,
                // 指定用于掩码的字符为 *，即使用星号替换指定范围内的字符
                "masking_char": "*"
            }
        }
    ]
}

2.2 静态脱敏模板

// 向 Elasticsearch 发送 PUT 请求，用于创建一个名为 gdpr_template 的索引模板
PUT _index_template/gdpr_template
{
    // 定义该索引模板所适用的索引模式
    "index_patterns": ["userdata-*"],
    // 这意味着此模板将应用于所有以 "userdata-" 开头的索引，方便对这类索引进行统一配置
    "template": {
        // 索引的设置部分，包含了一些关于索引行为的配置项
        "settings": {
            // 禁用字段类型强制转换。默认情况下，当输入的数据类型与映射中定义的类型不匹配时，Elasticsearch 可能会尝试进行强制转换。
            // 设置为 false 后，遇到不匹配的情况会抛出异常，保证数据类型的严格性
            "index.mapping.coerce": false,
            // 禁用对格式错误数据的忽略。当设置为 false 时，如果文档中包含格式不符合映射定义的数据，
            // Elasticsearch 不会忽略这些错误，而是会抛出异常，有助于确保数据的准确性
            "index.mapping.ignore_malformed": false
        },
        // 索引的映射部分，定义了索引中文档的结构和字段类型
        "mappings": {
            // 设置动态映射为严格模式。在严格模式下，当索引文档时，如果遇到映射中未定义的字段，
            // Elasticsearch 会拒绝该文档，避免意外添加未定义的字段，保证索引结构的稳定性
            "dynamic": "strict",
            // 定义文档中的具体字段及其属性
            "properties": {
                // 定义 "id_hash" 字段，其类型为 keyword
                // keyword 类型适用于需要精确匹配和排序的字段，通常用于存储哈希值、标签等
                "id_hash": { "type": "keyword" },
                // 定义 "name_masked" 字段
                "name_masked": { 
                    // 该字段的基本类型为 text，适用于需要进行全文搜索的字段
                    "type": "text",
                    // 指定该字段使用的分析器为 "partial_masking"。分析器会对文本进行分词等处理，
                    // 这里的 "partial_masking" 分析器应该是自定义的，用于处理部分掩码的文本
                    "analyzer": "partial_masking",
                    // 为 "name_masked" 字段添加一个子字段 "raw"，其类型为 keyword
                    // 这样可以同时满足全文搜索和精确匹配的需求，例如在需要精确匹配名称时可以使用 "name_masked.raw" 字段
                    "fields": { "raw": { "type": "keyword" } }
                }
            }
        }
    }
}

3. 脱敏算法性能对比

3.1 算法性能矩阵

3.2 存储成本分析

4. 企业级合规方案

4.1 金融行业案例

// 向 Elasticsearch 发送 PUT 请求，用于更新 bank_records 索引的设置
PUT /bank_records/_settings
{
    "index": {
        // 配置索引的映射相关设置，这里主要是字段掩码设置
        "mapping": {
            "field_masking": {
                // 对 credit_card 字段进行掩码处理
                "credit_card": {
                    // 指定使用的掩码类型为 FPE（Format Preserving Encryption，格式保留加密）
                    // FPE 可以在加密数据的同时保留数据的格式，方便后续处理和展示
                    "type": "FPE",
                    // 指定用于加密的密钥，这里使用名为 kms_v1_bank_key 的密钥
                    // 通常这个密钥会由密钥管理系统（KMS）进行管理，确保密钥的安全性
                    "key": "kms_v1_bank_key",
                    // 定义加密后数据的显示格式为 XXXX-XXXX-XXXX-####
                    // 这种格式保留了信用卡号的部分可见性，同时隐藏了关键信息
                    "format": "XXXX-XXXX-XXXX-####"
                }
            }
        },
        // 配置索引的数据保留策略
        "data_retention": {
            // 指定数据的保留时长为 730 天（两年）
            // 超过这个时间的数据将根据后续规则进行处理
            "delete_after": "730d",
            // 开启在删除数据前进行匿名化处理的选项
            // 这意味着在删除超过 730 天的数据之前，会先对数据进行匿名化，以保护用户隐私
            "anonymize_before_delete": true
        }
    }
}

• FPE（Format Preserving Encryption，格式保留加密）

  • 一种特殊的加密技术，其核心特点是加密后的数据保持原始格式（如长度、字符类型、结构等），同时确保敏感信息不可读。例如：
    • 信用卡号 1234-5678-9012-3456 加密后可能变为 XXXX-XXXX-XXXX-####（保留格式但隐藏关键数字）。
    • 社会安全号码 123-45-6789 加密后可能变为 XXX-XX-XXXX。
  • 典型应用场景
    • 金融行业：信用卡号、银行账号。
    • 医疗行业：患者 ID、社保号。
    • 政府机构：公民身份证号、税务信息。
    • 电商平台：用户手机号、地址。

• 实施效果：

4.2 医疗行业方案

# 这是一组医疗数据脱敏规则的配置，用于对医疗数据中的敏感信息进行处理，以保护患者隐私
# 每条规则由字段名、脱敏方法和相关参数组成

# 第一条规则：对患者ID字段进行脱敏处理
- field: patient_id  # 指定要进行脱敏处理的字段为 patient_id，通常患者ID是唯一标识患者身份的重要信息，需要进行严格保护
  method: HMAC-SHA256  # 采用 HMAC-SHA256 哈希算法进行脱敏。HMAC（Hash-based Message Authentication Code）是一种带密钥的哈希函数，SHA256 是安全哈希算法，能将数据转换为固定长度的哈希值，且具有不可逆性
  salt: "medical_salt_2023"  # 为哈希过程添加盐值 "medical_salt_2023"。盐值可以增加哈希结果的唯一性和安全性，防止通过彩虹表等方式破解哈希值

# 第二条规则：对诊断信息字段进行脱敏处理
- field: diagnosis  # 指定要进行脱敏处理的字段为 diagnosis，诊断信息包含患者的病情诊断结果，属于敏感信息
  method: keyword_masking  # 采用关键字掩码的方法进行脱敏，即通过正则表达式匹配部分内容并用特定字符替换
  pattern: "(?<=.{3})."  # 定义正则表达式模式。该模式使用正向肯定预查 (?<=.{3}) 匹配前三个字符之后的位置，然后匹配任意单个字符。意思是保留前三个字符，对后面的字符进行掩码处理
  replacement: "*"  # 指定将匹配到的字符替换为星号 *，从而实现对诊断信息部分内容的隐藏

# 第三条规则：对地理位置字段进行脱敏处理
- field: geo_location  # 指定要进行脱敏处理的字段为 geo_location，地理位置信息可能会暴露患者的居住地址等隐私
  method: geohash  # 采用地理哈希算法进行脱敏。地理哈希算法将经纬度编码为一个字符串，通过控制编码精度可以在一定程度上保护地理位置的隐私
  precision: 3  # 设置地理哈希的精度为 3。精度越高，编码后的字符串越长，能表示的地理位置越精确；精度为 3 时，编码后的字符串表示的地理位置范围相对较大，能有效保护患者的具体位置信息

5. 合规性验证方案

5.1 自动化检查脚本

def gdpr_compliance_check(index):
    """
    该函数用于检查指定 Elasticsearch 索引是否符合 GDPR（通用数据保护条例）合规要求。
    :param index: 要检查的 Elasticsearch 索引名称
    :return: 如果索引符合 GDPR 合规要求，返回 True；否则返回 False
    """
    # 步骤 1: 检查字段级加密
    # 使用 Elasticsearch 的 API 获取指定索引的映射信息，映射信息描述了索引中字段的类型和设置
    mapping = es.indices.get_mapping(index=index)
    # 筛选出映射中具有加密设置的字段。通过遍历映射中的每个字段，检查其映射配置中是否包含 'encryption' 键
    encrypted_fields = [f for f in mapping if 'encryption' in f.get('mapping', {})]
    # 这里可以进一步添加对加密字段的验证逻辑，例如检查加密算法是否符合要求等

    # 步骤 2: 验证数据脱敏
    # 从指定索引中随机抽取 10 条文档作为样本进行检查
    sample_docs = es.search(index=index, size=10)['hits']['hits']
    # 遍历抽取的样本文档
    for doc in sample_docs:
        # 调用自定义函数 is_sensitive_data_exposed 检查文档的源数据中是否存在敏感数据暴露的情况
        if is_sensitive_data_exposed(doc['_source']):
            # 如果存在敏感数据暴露，说明不符合 GDPR 要求，直接返回 False
            return False

    # 步骤 3: 检查保留策略
    # 使用 Elasticsearch 的 API 获取指定索引的索引生命周期管理（ILM）策略，ILM 策略用于管理索引的生命周期，包括数据保留时间等
    ilm_policy = es.ilm.get_lifecycle(index=index)
    # 检查 ILM 策略中设置的数据保留时间是否小于 730 天
    if ilm_policy['delete_after'] < '730d':
        # 如果保留时间小于 730 天，不符合 GDPR 关于数据保留的要求，返回 False
        return False

    # 如果上述所有检查都通过，说明该索引符合 GDPR 合规要求，返回 True
    return True

5.2 审计检查清单

• Nessus报告
  • Nessus 是全球领先的漏洞扫描工具，其报告通常包含以下关键信息：

    {
      "vulnerabilities": [
        {
          "plugin_id": 12345,
          "name": "Elasticsearch未授权访问",
          "risk_factor": "High",
          "description": "Elasticsearch服务未启用认证，可通过公网访问",
          "solution": "启用xpack.security并配置角色权限",
          "compliance": ["GDPR第32条", "HIPAA第164.312(a)(1)"]
        },
        {
          "plugin_id": 67890,
          "name": "弱密码策略",
          "risk_factor": "Medium",
          "description": "存在密码长度小于8位的账户",
          "solution": "强制密码复杂度策略",
          "compliance": ["GDPR第32条"]
        }
      ],
      "hosts": [
        {
          "ip": "192.168.1.100",
          "ports": ["9200/tcp"],
          "os": "CentOS 7",
          "plugins": [12345, 67890]
        }
      ]
    }
    

  • 集成到合规性检查流程

附录：GDPR工具生态

实施规范：

1. 建立数据分类分级标准
2. 实施最小权限原则
3. 每季度执行脱敏规则审计
4. 保留数据血缘追踪记录