敏感信息监控通用方案

背景：

  春节过后公司有个核心部门遭到竞争对手的强力挖角，所谓铁打的营盘流水的兵，人员的流失并不可怕，公司担心的是wiki这类的文档中心里的设计、方案、策划等核心资料外泄。所以必须要加强文档库敏感操作的监控，及时止损。

分析：

    如果文档库是开源或者自研产品，可以通过修改代码满足上述需求，如果像我们一样使用confluence这样的黑盒产品就比较头疼了。Confluence对内容的导出分为两个维度：项目维度和页面维度。其中项目维度的导出Confluence内置了审计日志，而且我们已经通过权限控制限定了只有超级管理员才能进行导出。Confluence没有提供页面级别的审计日志，这个就是我需要解决的问题。

思路：

    Web应用提供某一具体服务的url一般都会满足特定规则，我们要先尝试获取黑盒产品导出操作的url，如图：

   我们如果在confluence北向增加一层nginx反向代理，理论上我们可以获取到所有流经Nginx的请求报文，根据正则表达等方式就可以判断出是否属于敏感的url。
  只发现有人在导出资料还不足够，因为原始需求是要为公司止损，也就是说还要去找到“内鬼”。既然confluence有账号系统，那么肯定在http请求报文中藏有用户信息，一般都藏在header中，只不过具体的header哪个属性需要我们抓包去分析下。这个也很简单，直接通过chrome就可以做到。如图：

细节：

    经过上面的分析，核心问题就只剩下如何配置nginx了，我们既要能捕获到我们关心的敏感信息，也要放行非敏感信息，很幸运，nginx的最长匹配规则让问题变得再简单不过了。我们只要给敏感url配置好日志格式和专门的日志产出文件，问题就OK了。配置如下：

  #在外面定义好输出格式，至少要包含时间、页面标识和用户，有这三个属性监控才有意义。
  log_format exportFormat '"$time_local" "wiki" "$hostname" "$remote_addr" "$http_x_forwarded_for" "$status" "$upstream_addr" "$upstream_status" "$request_length" "$bytes_sent" "$request_time" "$upstream_response_time" "$request_method" "$server_protocol" "$host" "$request_uri" "$http_referer" "$request_body" "$http_user_agent" {"username":"$sent_http_x_ausername"}'; 
  
  # confidence非敏感路径
    location / {
        proxy_pass         http://XX.XX.XXX.XX:port;
        proxy_set_header   Host $host:443;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;
        proxy_set_header   X-Forwarded-Proto https;

        access_log      /var/log/nginx/wiki.access.log;
        error_log       /var/log/nginx/wiki.error.log;

        proxy_read_timeout  1200s;

        client_max_body_size 0;
    }

    location /spaces/flyingpdf/pdfpageexport.action {
        proxy_pass         http://XX.XX.XXX.XX:port;
        proxy_set_header   Host $host:443;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;
        proxy_set_header   X-Forwarded-Proto https;

        access_log      /var/log/nginx/wiki.pdfexportnew.log exportFormat;
        error_log       /var/log/nginx/wiki.error.log;

        proxy_read_timeout  1200s;

        client_max_body_size 0;
    }

    location /exportword {
        proxy_pass         http://XX.XX.XXX.XX:port;
        proxy_set_header   Host $host:443;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;
        proxy_set_header   X-Forwarded-Proto https;

        access_log      /var/log/nginx/wiki.wordexportnew.log exportFormat;
        error_log       /var/log/nginx/wiki.error.log;

        proxy_read_timeout  1200s;

        client_max_body_size 0;
    }

增强：

    目前为止我们做到了发现敏感操作并记录在案，为了最快速度止损，还需要配合告警系统。有很多种思路：同一账号3秒钟内连续操作两次；利用linux的邮件系统定时把相关日志发送给管理员来人工分析；捕获的敏感日志在短时间内size激增；或者以上都作为判断依据分配不同权重等等。总之如何甄别是真的工作需求还是内鬼行为，这里就需要一点“智慧”了。

推广：

    本文所阐述的是一种方法论，不限于confluence，也不限于nginx，其它网关和web服务也都适用，这里只是提供了一种解决黑盒产品敏感操作监控的思路。