记录一次敏感信息脱敏的过程

背景:

在A公司入职,老大让我去做数据脱敏,通过调用运维组的数据脱敏接口,保证用户的敏感的信息不落地。公司项目主要使用laravel5.1 和 YII1.1 版本。

具体方案:

敏感信息字段的调用存在与代码中的各个角落,如果手动对每一个地方的代码都去撸一边,所需要耗费的时间是非常巨大的,为了减少工作量,我们决定对model下手,考虑到并不是所有的model都存在脱敏信息,单独定义一个trait来处理存在敏感信息似乎是一个相对比较稳妥的方式。

我们对于脱敏的主要思想是对__get()和__set()两个魔术方法的改造,希望在最大程度的减少对使用类似User::model()->username的影响,以Yii1.1框架为例,还要改造findByAttributes()等方法避免大量findByXXX()方法的失效

public function __get($name)
{
    //getPlainKeys() 定义了model当中的需要的脱敏信息字段
    if(in_array($name, $this->getPlainKeys())) {
        $enc_name = Mask::getMaskName($name);//encrypt_username
        if(empty($this->$enc_name)) {
            return parent::($name); //兼容代码,用户数据未更新时调用
        }
        $plain_value = Mask::encrypt(Mask::getMaskType($name), $this->$name);//返回明文
        return $plain_value;
    }else {
        return parent::($name);//不要使用$this->$name 防止多次调用__get()
    }
}

重写完__get()的方法后,在定义一个getPlain()的方法,传入返回明文的字段,
通过User::model()->getPlain(['username'])->username的方法返回需要的明文就好了,在这之前,需要在需要脱敏的model里面加好订好的脱敏信息的字段$mask_key['username','mobile']

   /**
    * 往数组里塞值
    **/
    public function getPlain($keys)
    {
        foreach($keys as $key){
            if(in_array($key, $this->getMaskName())) {//比较mask_key
                array_merge($this->getPlainKeys(), $keys);         }
        }
        return $this;  
    }

当然了,如果直接通过User::model()->username的地方很多,又需要明文的地方很多,就在model里面直接添加一个$plain_keys的字段去默认返回明文就好了,同时去新增一个能够将$plain_keys里面的值移除的方法就好了,例如User::model()->removePlainKeys('username')->username返回打码明文就好了.

public function __set($name, $value)
{
    if(in_array($name, $this->getMaskKeys())){
        ... //产生字段名称encrypt_username, plain_username
        if(empty($value)) { //防止某些情况下可能发生的将敏感信息写回空值的情况,enccrypt_username 存在将回返回旧的历史数据
            $this->setAttributes($name, '');
            $this->setAttributes($encrypt_username, '');
            $this->setAttributes($plain_username, '');
        }
            $data = Mask::doencrypt(Mask::getMaskType($name),$value)
            $this->setAttributes($name, $data['plain_text']);
            $this->setAttributes($encrypt_username, $data['hash']);
            $this->setAttributes($plain_username, $value;
    }else {
        reutrn parent::__set($name, $vk)
    }
}
<think>嗯,用户问的是在资产处置过程中,一次HTTP交互是否需要记录为审计日志,以及记录的条件是什么。这其实是个很具体的技术操作问题,涉及安全审计的实践标准。从用户提到的几个引用来看,引用1和4都强调了日志审计的核心功能是安全监控和事件溯源,而引用2特别指出日志完整性的重要性——这意味着任何可能改变资产状态的操作都应该被记录。用户能这么问,说明ta应该是在设计或维护某个资产管理系统,对安全合规性有较高要求。具体到HTTP交互的记录标准,我认为需要分两层判断:第一层看操作性质(是否改变资产状态),第二层看风险等级(即使只读操作,如果是高危资产或敏感接口也要记录)。比如用户说的"资产处置"通常涉及资产转移、状态变更等敏感操作,这类交互肯定要记录。但如果是单纯的资产列表查询,可能就不需要记录。技术上有个细节要注意:引用3提到阿里云的方案用图形化处理审计日志,说明现在业界趋势是把所有可能涉及安全的操作都记录下来,通过后期分析工具来过滤噪音。所以从最佳实践角度,建议用户对资产处置相关的所有HTTP交互全量记录。安全方面还有个坑要提醒用户:引用2和4都强调日志防篡改的重要性。如果决定记录这些交互,一定要配套只写权限、加密存储等措施,否则审计日志本身被篡改就失去意义了。</think> 基于资产处置场景下的安全审计要求,**一次涉及资产处置的HTTP交互通常需要记录为审计日志**,但具体记录条件需结合操作敏感性和合规要求综合判断。以下是详细分析: --- ### **一、必须记录为审计日志的条件** 1. **操作触及资产核心属性变更** 当HTTP请求包含以下操作时,必须记录: - **资产状态变更**:报废、转移、封存等处置动作 - **权属变更**:责任人/归属部门调整 - **敏感数据操作**:资产参数(如IP地址、安全策略)的修改 *示例:* `PUT /api/asset/{id}/decommission`(资产报废请求)需完整记录请求参数、操作用户、时间戳[^4]。 2. **涉及高价值或受监管资产** 金融设备、敏感数据存储设备等受合规框架(如等保2.0、GDPR)约束的资产,所有交互均需记录[^2][^4]。 3. **执行结果影响安全态势** 若操作触发安全规则(如异常处置频率、越权行为),即使操作失败也需记录,用于关联分析攻击行为[^1][^2]。 --- ### **二、建议记录的技术关键字段** 完整审计日志应包含: | **字段** | **必要性** | **示例值** | |------------------|-----------|-------------------------------| | 请求唯一ID | 必需 | `req-5f3d87a2e12c8` | | 源IP+用户身份 | 必需 | `192.168.1.10; user=admin` | | HTTP方法+路径 | 必需 | `POST /asset-dispose` | | 关键请求参数 | 条件必需※ | `{"assetId": "SRV-2024-089"}` | | 响应状态码 | 必需 | `200` 或 `403` | | 操作时间戳 | 必需 | `2024-07-25T14:30:22Z` | > ※ 涉及资产标识、处置类型等参数必须记录,其他参数依策略脱敏 --- ### **三、可豁免记录的特殊场景** 1. **只读类查询操作** 如`GET /api/asset/list`(资产列表查询),若不含敏感字段且符合最小权限原则,可仅记录访问日志而非审计日志。 2. **自动化心跳检测** 运维探针的`HEAD /health-check`等存活检测请求,在无安全风险时可排除[^2]。 --- ### **四、实施建议** 1. **动态策略引擎** 采用日志分析系统(如引用1、3方案)配置规则: ```python # 伪代码:审计日志触发规则 if (request.path in ["/asset/dispose", "/asset/transfer"]) or (asset.value > 100000) or (request.user.role == "FINANCE"): log_full_audit(request) # 记录完整审计日志 ``` 2. **防篡改存储** - 日志直接写入专用审计库(非业务数据库) - 启用WORM(一次写入多次读取)存储策略[^2][^4] 3. **关联分析** 将资产处置日志与用户行为日志、网络流量日志关联,识别如`同一IP短时批量处置资产`的异常模式[^1][^3]。 --- ### **关键结论** > **资产处置中的HTTP交互需记录审计日志的核心场景**: > ✅ **影响资产生命周期的写操作**(处置/变更) > ✅ **高敏感资产相关操作** > ✅ **违反安全策略的行为** > ➠ 技术实现需保证**操作溯源能力**(Who/When/What)和**日志完整性**[^4][^2]。 --- **
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值