雖然微服務公平地分享他們的利益，但在安全性方面需要重視，包括新的威脅和工具。
隨著越來越多的組織從整體轉向更分散的基于微服務的體系結構，那么其安全性是否隨之提高？雖然有些事情有所改善，但微服務仍然存在一些重大的安全挑戰，開發人員和架構師將不得不面臨這些挑戰。
獨立技術顧問，Specto Labs公司首席技術官Daniel Bryant對提高微服務的安全性以及可以使用的一些工具和技術解決出現的一些挑戰進行了闡述。
與傳統架構相比，微服務在安全性方面面臨著哪些新挑戰？
Bryant：按照傳統的方法，如果有一件事妥協了，那就麻煩不斷。這就像將所有的雞蛋放在一個籃子里。另一方面，當事情弄糟之后，突然之間，就必須確保更多的事物的安全。然后隨著攻擊面變得越來越大，就不必再做類似硬化邊緣的事情。
現在最大的挑戰是每個開發人員必須更加意識到安全。還有更多的事情，還有更多的攻擊面，所有這些暴露的東西之間還有更多的溝通。
什么樣的工具和技術對于微服務安全性至關重要？
Bryant：有一些像Web應用程序防火墻這樣非常受歡迎的東西。很多公司使用F5這樣的工作，實際上就是F5防火墻。人們將越來越多地看到更多的軟件防火墻。
這顯然是預防，但也需要考慮檢測。因此，基本內容是：記錄通信中的低帶寬、記錄Web流量、記錄SSH[安全套接字shell]訪問。在任何面向公眾的Web服務器中，如果查看日志，人們就會不斷地探測邊緣。如果查看這個IP地址，或來自己哪個國家…需要對來自哪里的東西做某種類似于持續分析。
還有哪些攻擊呢？他們試圖探測什么向量？如果沒有修補系統，可能有一天會遭遇到黑客攻擊。所以肯定需要檢測，需要確保所有的修補完成。用戶將大量的費用花費在網絡上和計算上。這些是很好的東西，但不要忘記應用程序。如果應用程序有很大的漏洞，那么所有其他的東西都會受到損害。只有漏洞才會讓黑客進入，并開始造成傷害。
我認為像威脅建模這樣的東西也是非常有用的。了解威脅是如何工作的，存在哪些威脅，并建模它們可能如何攻擊系統。人們經常發現，正確地建模的副作用讓人們對事情發生的不同方式有了不同的認識。所以，如果開始做攻擊向量，會突然想，‘我真的在應用程序中強化了這個東西，’你會意識到你的電子郵件系統或其他東西有一個巨大的缺陷。
開放Web應用程序安全項目（OWASP），他們是一個非常優秀的組織。他們有一系列語言類型的診斷工具，用于掃描依賴關系中的關鍵漏洞。所以，如果使用Java或Maven，可以把它放在MavenPalm中。
在微服務安全性方面，每個人都應該問什么問題？
Bryant：人們該怎么做？問自己的團隊和管理層我該怎么辦？這樣的工作與安全有什么關系？應該遵守某些標準嗎？應該重新檢查工作嗎？這些東西是最關鍵的。
我認為微服務安全性與傳統安全性沒有大的不同。作為開發人員，人們的工作越來越多，必須成為一名操作人員以及開發人員。你知道，前端和后端，所有這些東西這么繁雜，那么技術人員的知識就會全面卻不深入。
與此同時，如果開發人員在整個堆棧中受過良好教育，但對安全性并不太了解，則很容易留下大量漏洞。如果留下一些巨大的安全漏洞，這可能是非常糟糕的。所以，開發意識，建模，記錄，分享，到會議，與人聊天，學習等這些因素都很重要。
專家們在微服務安全方面十分重視，但為什么還不能有效的解決呢？
Bryant：這并不是明確所指的是微服務。隨著世界越來越多的連接，像比特幣這樣的新生事物現在越來越受到攻擊者的攻擊。
我認為，IT行業并沒有像應該承擔的那樣負責任。所以，更重要的一個例子就是人為因素。作為開發人員還是作為架構師，人們是否對此給予足夠的關注？人們是不是做了像縱深防御之類的事情？人們是在做審計和記錄，然后回顧那些事情嗎？有一些基本的東西，比如編碼術語。這里再次重申，人們并沒有做到。
在安全性方面，傳統架構（如面向服務架構（SOA））與分布式微服務體系結構有何好轉？
Bryant：原則上沒有太大的變化。我唯一想說的是，在SOA中，我們有更多的治理。SOA是由供應商的法律驅動的。他們說，“你必須使用我的ESB（企業服務總線）或我的特定的技術”，這有很多缺點，但其中一個好處有這個ESB，可以管理服務中的所有連接。所以，他們真的投資于政策和治理以及所有這些事情。如果出了問題，你知道應該打電話聯系誰。
然而，這些天來，我們傾向于更輕量級的技術，但作為一名開發人員和架構師，必須承擔更多的責任。治理、政策和事物，盡管有時是糟糕的，但還是有好處的。擁有更多的控制權，其自由顯然就少了，但這是一種平衡。
DevOps團隊如何能夠與安全團隊合作，確保服務得到保障？
Bryant：DevOps的理念是讓大家加入。所以，很多顧問公司嘗試引入信息安全。在一個傳統的組織中，他們通常被稱為信息。讓他們早日進入項目，他們的知識是非常有價值的，所以讓他們早日參與是正確的舉措。
京公網安備 11010502049343號