最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接：
http://www.jianshu.com/p/48d17a69e190
http://mt.sohu.com/20170107/n478047698.shtml​ 
http://bbs.tianya.cn/post-itinfo-503786-1.shtml​ 
 
安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：
 
下载安装
 
     请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。
不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。
    链接君：https://www.elastic.co/downloads 
 
 
使用最新的 Elasticsearch
 
    请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。
    链接君：https://www.elastic.co/downloads
 
 
修改默认的 Elasticsearch 集群名称
 
     Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。
    文档君：https://www.elastic.co/guide/e ... .name
 
 不要暴露 Elasticsearch 在公网上
 
      Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：

1. 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
2. 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。

 
     文档君：https://www.elastic.co/guide/e ... tings 
 
禁用批量删除索引
 
Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。

安全使用动态脚本

     Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。
      Elasticsearch 默认启用了  Java Security Manager ，但还请正确配置其白名单。
      使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。
      文档君：https://www.elastic.co/guide/e ... .html
 
给 Elasticsearch 服务器加固
 
     服务器加固是一个必备流程，不管上面运行的是什么服务；
     首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；
     如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。
     关注 Java 最新的漏洞，使用安全的 JVM 运行时。
     服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。
     收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。
 
不要以 root 身份运行 Elasticsearch

    如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。
     范例君：

sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m"  /opt/elasticsearch/bin/elasticsearc

 
正确设置 Elasticsearch 的数据目录
 
     请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。
     文档君：https://www.elastic.co/guide/e ... tings
 
定期对 Elasticsearch 进行备份
 
     使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。
     文档君：https://www.elastic.co/guide/e ... .html
 
加上监控和预警
 
     Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:

1. 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
2. 使用其他厂商的安全监控产品。
3. 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。

是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。
 
以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。 

最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报：
https://www.elastic.co/community/security
企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接：
https://www.elastic.co/cn/contact

招聘需求：
 
技术总监1名：
1、 日志分析产品研发经验优先，8年以上工作经验
2、 精通elasticsearch、Redis、MongoDB、Neo4J等NoSQL系统，熟悉elasticsearch集群管理和性能调优，有在实际项目中使用搜索引擎工具、内存数据库、文档数据库、图数据库的经验
3、 熟悉Hadoop、Spark、Spark Streaming、Storm、HBase、ZooKeeper等大数据生态系统组件;熟悉Kafka、ZeroMQ等消息系统组件
4、 精通日志处理工具集ELK，flume，heka等
5、 熟悉Linux环境，熟练使用Python和Shell进行脚本编程
6、 精通JAVA语言，熟悉主流开源框架Struts2、Spring、Hibernate，SpringMVC的运行机制及使用。熟练掌握和使用J2EE开发中常见面向对象设计模式(Singleton，Proxy，Factory等)
7、 有系统运维管理平台项目开发及管理经验优先
8、 提供优厚待遇及期权，薪水50万以上
9、 金融行业背景优先考虑
 
 
技术专家2名：
1、熟悉Hadoop生态圈相关技术，如Hbase，Hive，Zookeeper，flume，kafka，storm
2、了解spark运行机制，研读spark部分内核源码；了解ELK日志分析平台（elasticsearch、logstash、kibana）使用
3、 熟悉Linux系统的基本操作和集群环境的搭建和部署
4、 熟悉JavaEE的开发，掌握JavaEE流行框架的使用，如：Struts2、Spring、Hibernate、SpringMVC等
5、熟悉主流数据库Oracle、DB2、MySQL、Mariadb的使用及性能优化；会使用NoSql数据库（如redis）解决开发过程中遇到的业务问题
6、提供优厚待遇和期权，薪水30万以上
7、金融行业优先考虑
如有意向请联系郝女士   联系电话：13520834022      邮箱：haojinjin16@163.com
招聘单位：洋大数据信息技术（北京）有限公司

转载：http://www.infoq.com/cn/news/2 ... nTool
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122 



早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。

作为运维人员，我亟须优化日志搜索

开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。

于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。

在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。

编程吧，动手创造自己的工具

的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。

编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。

“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。

在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。

不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。

从来没有犹豫过是否开源

12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。

开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。

当时的小愿望，现在的大公司

Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。



我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。

Kibana的下一步：数据挖掘、角色报表

1、数据挖掘，精益求精

最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。

一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。

基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。

2、接下来，Dashboard不会只有public一种

此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。

接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。

Kibana in Elastic Stack 5.0



研发情况

研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。

如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。

会一直并且只是配合Elasticsearch

是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。

最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。

Kibana的美学

Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。

你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。

写在最后

在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：

如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。