mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Xingyu.Wang
GitHub
commit
09184147f6
@ -1,61 +0,0 @@
|
||||
Translating by MjSeven
|
||||
|
||||
|
||||
What developers need to know about security
|
||||
======
|
||||
|
||||
|
||||
|
||||
DevOps doesn't mean that everyone needs to be an expert in both development and operations. This is especially true in larger organizations in which roles tend to be more specialized. Rather, DevOps thinking has evolved in a way that makes it more about the separation of concerns. To the degree that operations teams can deploy platforms for developers (whether on-premises or in a public cloud) and get out of the way, that's good news for both teams. Developers get a productive development environment and self-service. Operations can focus on keeping the underlying plumbing running and maintaining the platform.
|
||||
|
||||
It's a contract of sorts. Devs expect a stable and functional platform from ops. Ops expects that devs will be able to handle most of the tasks associated with developing apps on their own.
|
||||
|
||||
Devs expect a stable and functional platform from ops. Ops expects that devs will be able to handle most of the tasks associated with developing apps on their own.
|
||||
|
||||
That said, DevOps is also about better communication, collaboration, and transparency. It works better if it's not about merely a new type of wall between dev and ops. Ops needs to be sensitive to the type of tools developers want and need and the visibility they require, through monitoring and logging, to write better applications. Conversely, developers need some awareness of how the underlying infrastructure can be used most effectively and what can keep operations up at night (literally).
|
||||
|
||||
That said, DevOps is also about better communication, collaboration, and transparency. It works better if it's not about merely a new type of wall between dev and ops. Ops needs to be sensitive to the type of tools developers want and need and the visibility they require, through monitoring and logging, to write better applications. Conversely, developers need some awareness of how the underlying infrastructure can be used most effectively and what can keep operations up at night (literally).
|
||||
|
||||
The same principle applies more broadly to DevSecOps, a term that serves to explicitly remind us that security needs to be embedded throughout the entire DevOps pipeline from sourcing content to writing apps, building them, testing them, and running them in production. Developers (and operations) don't suddenly need to become security specialists in addition to the other hats they already wear. But they can often benefit from a greater awareness of security best practices (which may be different from what they've become accustomed to) and shifting away from a mindset that views security as some unfortunate obstacle.
|
||||
|
||||
Here are a few observations.
|
||||
|
||||
The Open Web Application Security Project ([OWASP][1]) [Top 10 list][2] provides a window into the top vulnerabilities in web applications. Many entries on the list will be familiar to web programmers. Cross-site scripting (XSS) and injection flaws are among the most common. What's striking though is that many of the flaws on the original 2007 list are still on 2017's list ([PDF][3]). Whether it's training or tooling that's most at fault, many of the same coding flaws keep popping up.
|
||||
|
||||
The situation is exacerbated by new platform technologies. For example, while containers don't necessarily require applications to be written differently, they dovetail with new patterns (such as [microservices][4] ) and can amplify the effects of certain security practices. For example, as my colleague [Dan Walsh][5] [@rhatdan][6] ) writes, "The biggest misconception in computing [is] you need root to run applications. The problem is not so much that devs think they need root. It is that they build this assumption into the services that they build, i.e., the services cannot run without root, making us all less secure."
|
||||
|
||||
Was defaulting to root access ever a good practice? Not really. But it was arguably (maybe) a defensible one with applications and systems that were otherwise sufficiently isolated by other means. But with everything connected, no real perimeter, multi-tenant workloads, users with many different levels of access rights—to say nothing of an ever more dangerous threat environment—there's far less leeway for shortcuts.
|
||||
|
||||
[Automation][7] should be an integral part of DevOps anyway. That automation needs to include security and compliance testing throughout the process. Where did the code come from? Are third-party technologies, products, or container images involved? Are there known security errata? Are there known common code flaws? Are secrets and personally identifiable information kept isolated? How do we authenticate? Who is authorized to deploy services and applications?
|
||||
|
||||
You're not writing your own crypto, are you?
|
||||
|
||||
Automate penetration testing where possible. Did I mention automation? It's an essential part of making security continuous rather than a checklist item that's done once in a while.
|
||||
|
||||
Does this sound hard? It probably is a bit. At least it may be different. But as a participant in a [DevOpsDays OpenSpaces][8] London said to me: "It's just technical testing. It's not magical or mysterious." He went on to say that it's not even that hard to get involved with security as a way to gain a broader understanding of the whole software lifecycle (which is not a bad skill to have). He also suggested taking part in incident response exercises or [capture the flag exercises][9]. You might even find they're fun.
|
||||
|
||||
This article is based on [a talk][10] the author will be giving at [Red Hat Summit 2018][11], which will be held May 8-10 in San Francisco. _[Register by May 7][11] to save US$ 500 off of registration. Use discount code **OPEN18** on the payment page to apply the discount._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/4/what-developers-need-know-about-security
|
||||
|
||||
作者：[Gordon Haff][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/ghaff
|
||||
[1]:https://www.owasp.org/index.php/Main_Page
|
||||
[2]:https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
|
||||
[3]:https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
|
||||
[4]:https://opensource.com/tags/microservices
|
||||
[5]:https://opensource.com/users/rhatdan
|
||||
[6]:https://twitter.com/rhatdan
|
||||
[7]:https://opensource.com/tags/automation
|
||||
[8]:https://www.devopsdays.org/open-space-format/
|
||||
[9]:https://dev.to/_theycallmetoni/capture-the-flag-its-a-game-for-hacki-mean-security-professionals
|
||||
[10]:https://agenda.summit.redhat.com/SessionDetail.aspx?id=154677
|
||||
[11]:https://www.redhat.com/en/summit/2018
|
||||
@ -0,0 +1,55 @@
|
||||
关于安全，开发人员需要知道的
|
||||
======
|
||||
（to 校正：有些长句子理解得不好，望见谅）
|
||||
|
||||
|
||||
DevOps 并不意味着每个人都需要成为开发和运维方面的专家。尤其在大型组织中，其中角色往往更加专业化。相反，DevOps 思想在某种程度上更多地是关注问题的分离。在某种程度上，运维团队可以为开发人员（无论是在本地云还是在公共云中）部署平台，并且不受影响，这对两个团队来说都是好消息。开发人员可以获得高效的开发环境和自助服务，运维人员可以专注于保持基础管道运行和维护平台。
|
||||
|
||||
这是一种约定。开发者期望从运维人员那里得到一个稳定和实用的平台，运维人员希望开发者能够自己处理与开发应用相关的大部分任务。
|
||||
|
||||
也就是说，DevOps 还涉及更好的沟通、合作和透明度。如果它不仅仅是一种介于开发和运维之间的新型壁垒，它的效果会更好。运维人员需要对开发者想要和需要的工具类型以及他们通过监视和日志记录来编写更好应用程序所需的可见性保持敏感。相反，开发人员需要了解如何才能使底层基础设施更有效地使用，以及什么能够在夜间（字面上）保持操作。（to 校正：这里意思是不是在无人时候操作）
|
||||
|
||||
同样的原则也适用于更广泛的 DevSecOps，这个术语明确地提醒我们，安全需要嵌入到整个 DevOps 管道中，从获取内容到编写应用程序、构建应用程序、测试应用程序以及在生产环境中运行它们。开发人员（和运维人员）不需要突然成为安全专家，除了他们的其它角色。但是，他们通常可以从对安全最佳实践（这可能不同于他们已经习惯的）的更高认识中获益，并从将安全视为一些不幸障碍的心态中转变出来。
|
||||
|
||||
以下是一些观察结果。
|
||||
|
||||
开放式 Web 应用程序安全项目（Open Web Application Security Project）（[OWASP][1]）[Top 10 列表]提供了一个窗口，可以了解 Web 应用程序中的主要漏洞。列表中的许多条目对 Web 程序员来说都很熟悉。跨站脚本（XSS）和注入漏洞是最常见的。但令人震惊的是，2007 年列表中的许多漏洞仍在 2017 年的列表中（[PDF][3]）。无论是培训还是工具，都有问题，许多相同的编码漏洞在不断出现。（to 校正：这句话不清楚）
|
||||
|
||||
新平台技术加剧了这种情况。例如，虽然容器不一定要求应用程序以不同的方式编写，但是它们与新模式（例如[微服务][4]）相吻合，并且可以放大某些对于安全实践的影响。例如，我的同事 [Dan Walsh][5]（[@rhatdan][6]）写道：“计算机领域最大的误解是需要 root 权限来运行应用程序，问题是并不是所有开发者都认为他们需要 root，而是他们将这种假设构建到他们建设的服务中，即服务无法在非 root 情况下运行，而这降低了安全性。”
|
||||
|
||||
默认使用 root 访问是一个好的实践吗？并不是。但它可能（也许）是一个可以防御的应用程序和系统，否则就会被其它方法完全隔离。但是，由于所有东西都连接在一起，没有真正的边界，多用户工作负载，拥有许多不同级别访问权限的用户，更不用说更加危险的环境了，那么快捷方式的回旋余地就更小了。
|
||||
|
||||
[自动化][7]应该是 DevOps 不可分割的一部分。自动化需要覆盖整个过程中，包括安全和合规性测试。代码是从哪里来的？是否涉及第三方技术、产品或容器映像？是否有已知的安全勘误表？是否有已知的常见代码缺陷？秘密和个人身份信息是否被隔离？如何进行身份认证？谁被授权部署服务和应用程序？
|
||||
|
||||
你不是在写你自己的加密代码吧？
|
||||
|
||||
尽可能地自动化渗透测试。我提到过自动化没？它是使安全性持续的一个重要部分，而不是偶尔做一次的检查清单。
|
||||
|
||||
这听起来很难吗？可能有点。至少它是不同的。但是，作一名 [DevOpsDays OpenSpaces][8] 伦敦论坛的一名参与者对我说：“这只是技术测试。它既不神奇也不神秘。”他接着说，将安全作为一种更广泛地了解整个软件生命周期（这是一种不错的技能）的方法来参与进来并不难。他还建议参加事件响应练习或[捕获国旗练习][9]。你会发现它们很有趣。
|
||||
|
||||
本文基于作者将于 5 月 8 日至 10 日在旧金山举行的 [Red Hat Summit 2018][11] 上发表的演讲。_[5 月 7 日前注册][11]以节省 500 美元的注册。使用折扣代码**OPEN18**在支付页面应用折扣_
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/4/what-developers-need-know-about-security
|
||||
|
||||
作者：[Gordon Haff][a]
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/ghaff
|
||||
[1]:https://www.owasp.org/index.php/Main_Page
|
||||
[2]:https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
|
||||
[3]:https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
|
||||
[4]:https://opensource.com/tags/microservices
|
||||
[5]:https://opensource.com/users/rhatdan
|
||||
[6]:https://twitter.com/rhatdan
|
||||
[7]:https://opensource.com/tags/automation
|
||||
[8]:https://www.devopsdays.org/open-space-format/
|
||||
[9]:https://dev.to/_theycallmetoni/capture-the-flag-its-a-game-for-hacki-mean-security-professionals
|
||||
[10]:https://agenda.summit.redhat.com/SessionDetail.aspx?id=154677
|
||||
[11]:https://www.redhat.com/en/summit/2018
|
||||
Loading…
Reference in New Issue
Block a user