關於安全，開發人員需要知道的

DevOps 並不意味著每個人都需要成為開發和運維方面的專家。尤其在大型組織中，其中角色往往更加專業化。相反，DevOps 思想在某種程度上更多地是關注問題的分離。在某種程度上，運維團隊可以為開發人員（無論是在本地雲還是在公共雲中）部署平台，並且不受影響，這對兩個團隊來說都是好消息。開發人員可以獲得高效的開發環境和自助服務，運維人員可以專註於保持基礎管道運行和維護平台。

這是一種約定。開發者期望從運維人員那裡得到一個穩定和實用的平台，運維人員希望開發者能夠自己處理與開發應用相關的大部分任務。

也就是說，DevOps 還涉及更好的溝通、合作和透明度。如果它不僅僅是一種介於開發和運維之間的新型壁壘，它的效果會更好。運維人員需要對開發者想要和需要的工具類型以及他們通過監視和日誌記錄來編寫更好應用程序所需的可見性保持敏感。另一方面，開發人員需要了解如何才能更有效地使用底層基礎設施，以及什麼能夠使運維在夜間（字面上）保持運行。

同樣的原則也適用於更廣泛的 DevSecOps，這個術語明確地提醒我們，安全需要嵌入到整個 DevOps 管道中，從獲取內容到編寫應用程序、構建應用程序、測試應用程序以及在生產環境中運行它們。開發人員（和運維人員）除了他們已有的角色不需要突然成為安全專家。但是，他們通常可以從對安全最佳實踐（這可能不同於他們已經習慣的）的更高認識中獲益，並從將安全視為一些不幸障礙的心態中轉變出來。

以下是一些觀察結果。

開放式 Web 應用程序安全項目 Open Web Application Security Project （OWASP）[Top 10 列表]提供了一個窗口，可以了解 Web 應用程序中的主要漏洞。列表中的許多條目對 Web 程序員來說都很熟悉。跨站腳本（XSS）和注入漏洞是最常見的。但令人震驚的是，2007 年列表中的許多漏洞仍在 2017 年的列表中（PDF）。無論是培訓還是工具，都有問題，許多同樣的編碼漏洞一再出現。

新的平台技術加劇了這種情況。例如，雖然容器不一定要求應用程序以不同的方式編寫，但是它們與新模式（例如微服務）相吻合，並且可以放大某些對於安全實踐的影響。例如，我的同事 Dan Walsh（@rhatdan）寫道：「計算機領域最大的誤解是需要 root 許可權來運行應用程序，問題是並不是所有開發者都認為他們需要 root，而是他們將這種假設構建到他們建設的服務中，即服務無法在非 root 情況下運行，而這降低了安全性。」

默認使用 root 訪問是一個好的實踐嗎？並不是。但它可能（也許）是一個可以防禦的應用程序和系統，否則就會被其它方法完全隔離。但是，由於所有東西都連接在一起，沒有真正的邊界，多用戶工作負載，擁有許多不同級別訪問許可權的用戶，更不用說更加危險的環境了，那麼快捷方式的迴旋餘地就更小了。

自動化應該是 DevOps 不可分割的一部分。自動化需要覆蓋整個過程中，包括安全和合規性測試。代碼是從哪裡來的？是否涉及第三方技術、產品或容器鏡像？是否有已知的安全勘誤表？是否有已知的常見代碼缺陷？機密信息和個人身份信息是否被隔離？如何進行身份認證？誰被授權部署服務和應用程序？

你不是自己在寫你的加密代碼吧？

儘可能地自動化滲透測試。我提到過自動化沒？它是使安全性持續的一個重要部分，而不是偶爾做一次的檢查清單。

這聽起來很難嗎？可能有點。至少它是不同的。但是，一名 DevOpsDays OpenSpaces 倫敦論壇的參與者對我說：「這只是技術測試。它既不神奇也不神秘。」他接著說，將安全作為一種更廣泛地了解整個軟體生命周期的方法（這是一種不錯的技能）來參與進來並不難。他還建議參加事件響應練習或奪旗練習。你會發現它們很有趣。

via: https://opensource.com/article/18/4/what-developers-need-know-about-security

作者：Gordon Haff 選題：lujun9972 譯者：MjSeven 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive