你的数据会送老板进监狱么

　　欢迎各位阅读本篇文章，本篇文章讲述了教大家如何在CTO中计划任务，编程学习网教育平台提醒各位：本篇文章纯干货~因此大家一定要认真阅读本篇文章哦

　　各互金公司CTO们请看好你们家的爬虫，要不然一不小心就会把老板(法人代表)送进监狱，不是闹着玩的，按2017年6月1日以及最新刑事司法解释：

　　– 未经授权爬取用户手机通讯录超过50条记录，老板进去最高可达3年

　　– 未经授权抓取用户淘宝交易记录超过500条的，老板进去最高可达3年

　　– 未经授权读取用户运营商网站通话记录超过500条以上的，老板进去最高可达7年

　　– 未经授权读取用户公积金社保记录的超过50000条的，老板进去

　　启用 safe-update 选项，避免没有 WHERE 条件的全表数据被修改;

　　在应用中尽量不直接DELETE删除数据，而是设置一个标志位就好了。需要真正删除时，交由DBA先备份后再物理删除，避免误操作删除全部数据。

　　还可以采用触发器来做一些辅助功能，比如防止黑客恶意篡改数据。

　　3. MySQL账号权限规则

　　业务帐号，权限最小化，坚决不允许DROP、TRUNCATE权限。

　　业务账号默认只授予普通的DML所需权限，也就是select、update、insert、delete、execute等几个权限，其余不给。

　　MySQL初始化后，先行删除无用账号，删除匿名test数据库

　　mysql> delete from mysql.user where user!='root' or host!='localhost'; flush privileges;

　　mysql> drop database test;

　　创建备份专用账号，只有SELECT权限，且只允许本机可登入。

　　设置MySQL账号的密码安全策略，包括长度、复杂性。

　　4. 关于数据备份

　　记住， 做好数据全量备份是系统崩溃无法修复时的最后一概救命稻草 。

　　备份数据还可以用来做数据审计或是用于数据仓库的数据源拉取之用 。

　　一般来说，备份策略是这样的： 每天一次全备，并且定期对binlog做增备，或者直接利用binlog server机制将binlog传输到其他远程主机上 。有了全备+binlog，就可以按需恢复到任何时间点。

　　特别提醒：当采用xtrabackup的流式备份时，考虑采用加密传输，避免备份数据被恶意截取。

　　外网安全策略

　　事实上，操作系统安及应用安全要比数据库自身的安全策略更重要。同理，应用程序及其所在的服务器端的系统安全也很重要，很多数据安全事件，都是通过代码漏洞入侵到应用服务器，再去探测数据库，最后成功拖库。

　　1. 操作系统安全建议

　　运行MySQL的Linux必须只运行在内部网络，不允许直接对公网暴露，实在有需要从公网连接的话，再通过跳板机做端口转发，并且如上面所述，要严格限制数据库账号权限级别。

　　系统账号都改成基于ssh key认证，不允许远程密码登入，且ssh key的算法、长度有要求以确保相对安全。这样就没有密码丢失的风险，除非个人的私钥被盗。

　　进一步的话，甚至可以对全部服务器启用PAM认证，做到账号的统一管理，也更方便、安全。

　　关闭不必要的系统服务，只开必须的进程，例如 mysqld、sshd、networking、crond、syslogd 等服务，其它的都关闭。

　　禁止root账号远程登录。

　　禁止用root账号启动mysqld等普通业务服务进程。

　　sshd服务的端口号建议修改成10000以上。

　　在不影响性能的前提下，尽可能启用对MySQL服务端口的防火墙策略(高并发时，采用iptables可能影响性能，建议改用ip route策略)。

　　GRUB必须设置密码，物理服务器的Idrac/imm/ilo等账号默认密码也要修改。

　　每个需要登入系统的员工，都使用每个人私有帐号，而不是使用公共账号。

　　应该启用系统层的操作审计，记录所有ssh日志，或利bash记录相应的操作命令并发送到远程服务器，然后进行相应的安全审计，及时发现不安全操作。

　　正确设置MySQL及其他数据库服务相关目录权限，不要全是755，一般750就够了。

　　可以考虑部署堡垒机，所有连接远程服务器都需要先通过堡垒机，堡垒机上就可以实现所有操作记录以及审计功能了。

　　脚本加密对安全性提升其实没太大帮助。对有经验的黑客来说，只要有系统登入权限，就可以通过提权等方式轻松获得root。

　　2. 应用安全建议

　　禁用web server的autoindex配置。

　　从制度层面，杜绝员工将代码上传到外部github上，因为很可能存在内部IP、账号密码泄露的风险，真的要上传必须先经过安全审核。

　　尽量不要在公网上使用开源的cms、blog、论坛等系统，除非做过代码安全审计，或者事先做好安全策略。这类系统一般都是黑客重点研究对象，很容易被搞;

　　在web server层，可以用一些安全模块，比如nginx的WAF模块;

　　在app server层，可以做好代码安全审计、安全扫描，防止XSS攻击、CSRF攻击、SQL注入、文件上传攻击、绕过cookie检测等安全漏洞;

　　应用程序中涉及账号密码的地方例如JDBC连接串配置，尽量把明文密码采用加密方式存储，再利用内部私有的解密工具进行反解密后再使用。或者可以让应用程序先用中间账号连接proxy层，再由proxy连接MySQL，避免应用层直连MySQL;

　　最后我们想说， 任何高明的安全策略，都不如内部员工的安全意识来的重要 。以前发生过一起案例，公司内有位员工的PC不慎中毒，结果导致内网数据被盗。

　　安全无小事，每个人都应铭记于心。在数据安全面前，可以适当牺牲一些便利性，当然也不能太过，否则可能得不偿失。

　　最高可达7年

　　更多的违规情况就不一一举例了。 就以上几种数据，作为有效的信用基础数据，有几家互金公司不在用的?各位的爬虫完全合法地取得用户授权了么?有多少爬虫完全忽略robots.txt内容肆意横行的?有多少爬虫甚至暴力破解人家网站密码的……

　　如果是以销售数据为主营业务的大数据公司，更加要注意，因为一不小心你卖了点数据给犯罪分子，造成了恶劣的社会影响，要从重从严的判决。到目前为止，实务中由于审判人员对个人信息犯罪的危害性并不确定，大部分法院是作出法定刑三年以下的判决，但是最新的法条对重刑情节予以明确，量刑本身起点低，如依违法所得标准，违法所得在5万以上的，即可构成重刑。因此有学者预测式实施后，侵害个人信息犯罪适用重刑可能会出现激增现象。

　　大数据行业近日风声鹤唳，据一本财经报道，“数据堂”多人被警方调查，导致部分数据业务线停摆。至于被调查原因，知情人称，数据堂曾给一家理财营销公司提供了大量涉及用户隐私的数据。数据堂的主要商业模式是通过网络爬虫、公共领域共享等方式获取数据，而后对数据进行处理，而后向客户提供服务获取收益。 在没有得到任何授权的情况下，数据堂为理财营销公司提供用户数据有数据倒卖的嫌疑。除此之外，另有15家公司进入了调查名单，都是一些明目张胆，做得颇为过分的公司，其中几家大数据公司，估值已几十亿。

　　一些技术能力溢出的互金公司，已经在做类似数据公司的业务，对外以各种形式输出自身积累的数据，高管层的法律风险也逐渐显现。

　　司法解释里面提到以下集中类型的数据，无论是“非法提供”和“非法获取”都可以入刑：

　　第一类：高度敏感信息，包括四种信息：行踪轨迹信息、通信内容、征信信息、财产信息。涉及高度敏感信息的违法活动，由于定罪门槛最低，因此严格限制在此四类，不做任何扩展;

　　第二类：敏感信息，即住宿信息、通信记录、健康生理信息、交易信息等其他可能影响人身、财产安全的公民个人信息。与第一类相比较，《解释》对第二类信息的界定仍留有空间，意味着在司法实践中，仍有可能会出现目前所列举之外的第二类信息类型;

　　第三类：其他个人信息。即上述第二、三类以外的个人信息。个人信息的类型是定罪量刑的重要依据。越敏感信息，达到定罪门槛的信息数量越少。

　　只要违反国家规定获取个人信息，信息获取者无法主张其获取信息的正当理由的，无论是以“窃取”等本身非法的手段来获取，还是以“购买、收受、交换”等其他手段，都可被认为“非法获取”。

　　就互联网数据而言，目前主要的取得方式是利用爬虫自动搜索并抓取数据，爬虫协议要求所有网站在其站点的根目录下放置一个“robots.txt”文件，该文件告诉搜索者本站点哪些数据可以被“抓取”。这就意味着如果有人突破“robots.txt”范围抓取网站数据就要承担“侵犯数据”的法律责任。

　　在用户手机App端，如果未经用户明确授权，提取用户姓名、通信通讯联系方式、账号密码、行踪轨迹等信息，也必须承担法律责任。至于用户授权的形式，法律虽未明确，但如果存在恶意诱导和欺骗的行为要求用户授权，则很有可能招致刑罚。法律的导向是，任何个人身份信息，以电子或者其他方式记录的能够单独或者与其他信息结合识别特定自然人身份或者反映特定自然人活动情况的各种信息，未来都将受到严格的隐私权保护。

　　社会对个人隐私的保护越来越到位，是一件好事，互金数据乱象已久，大家可能都离风险比较近，无论是内部采集还是外购，总之一句话，爬虫有风险，抓数需谨慎，干活之前先跟自家法务勾兑清楚。

　　相信最后大家阅读完毕本篇文章，肯定学到了不少知识吧?其实大家私下还得多多自学，当然如果大家还想了解更多方面的详细内容的话呢，不妨关注编程学习网教育平台，在这个学习知识的天堂中，您肯定会有意想不到的收获的!