云原生环境中的安全性
source link: http://www.10tiao.com/html/625/201806/2652506667/2.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
云原生设计可提供巨大的安全性，但实现此目标需要采用结构化设计方法来保护企业系统和数据。
在服务及其消费者无处不在的时代，企业系统和数据的安全风险正在爆炸式增长。来自云服务供应商的安全产品是有前途的，但仍然是传统的，有时是安全攻击的软目标。
虽然企业CIO希望应用程序，基础架构和关键数据从防火墙后面转移到云中运行，但系统架构师和设计人员发现他们在自定义安全植入和云提供商产品之间混杂着。
你对互联网流量的安全感有多强烈？ 第三方光纤供应商是否保证无入侵管道？ 对于CIO来说，这些都是一些有趣的问题，大多数情况下答案并不如预期。 但是，组织可以提高他们的安全系统，使黑客入侵越来越困难，昂贵和耗时。
虽然有许多企业防火墙和VPN设备选项可用于数据中心或云环境，但重要的是包括访问控制，身份验证和授权等安全功能内置于应用程序层，而不仅仅依赖于网络安全。应用程序级安全实现使得访问控制可伸缩，可移植且不可变。访问是基于应用程序或服务或微服务的真实身份进行管理的，而不是基于人员配置。
云中的安全
安全系统是一个可靠的系统。云原生应用程序是安全的应用程序。跨云区域打包和部署的应用程序代码在各种容器中执行，并且可以被许多客户端或客户端应用程序访问。这使得在云环境中保护应用程序变得更加关键。
但是，编写安全代码并不像业务逻辑那么令人感兴趣，往往与安全相关的任务一直持续到最后一刻，导致产品安全功能的重大折衷。这不是一个好习惯。
如果你正在构建可扩展以支持大容量，可跨不同数据中心实例运行的云解决方案，并且可以半自动或全自动配置，则需要将安全性视为体系结构的核心构建块之一。
云原生微服务的数量呈指数增长，而物联网的兴起正在创造越来越多的接口和服务端点 - 这使得基于角色的认证保护应用端点变得更加重要。每个传入的请求都知道调用者及其相对于被调用的应用程序端点的角色。这些角色本质上决定了调用客户端是否有足够的权限在被调用的应用程序上执行请求的操作。
认证和授权模式
尽管软件安全本质上并没有“云原生”，但在保护你计划在云中部署的云云上应用程序时，需要避免一些事情并采取一些最佳实践。有许多工具和技术可用于提供应用程序安全性。云中一些最受欢迎的选项是OAuth，OpenID，SAML和HTTP基本认证。虽然他们都涵盖了相同的基础知识，但他们的方法和实施方式存在根本性差异。
如RFC 6749中所述的OAuth（开放授权）：“OAuth 2.0授权框架允许第三方应用程序通过编排资源所有者和用户之间的批准交互来代表资源所有者获得对HTTP服务的有限访问HTTP服务，或者允许第三方应用程序以自己的名义获得访问权。“
简而言之，OAuth是基于令牌的授权的开放标准，它允许用户的帐户信息被第三方应用程序或系统（如Facebook）使用，而不会以受控方式暴露用户的凭证。
OpenID Connect建立在OAuth2授权框架之上，旨在提供额外的身份验证功能。 OpenID Connect还旨在通过避免XML和SOAP开销来降低复杂性，就像大多数SAML用例一样。 OpenID允许用户通过称为身份提供商的第三方服务进行身份验证。用户可以选择他们首选的OpenID提供程序来登录到接受OpenID身份验证方案的应用程序或系统。
SAML，一种基于XML的开放标准数据格式，用于在承载Web应用程序的服务提供商与维护和提供电子身份的身份提供商（如Linkedin，Facebook和Google）之间交换授权和身份验证数据。 SAML提供了一种安全的方式来在不断扩大的平台世界中对用户进行身份验证和授权。 SAML还通过支持平台独立访问Web应用程序，以云原生方式实现更强大的健壮性，而无需IT团队参与角色配置。
设计上的安全性
遵循云原生方式的架构师和设计师坚持使用云原生应用程序开发的12个要素，以构建和实施使用外部配置的无状态服务。在设计一个安全的云原生应用程序时，一些非常基本的设计方法是：
凭证和端点：始终将服务凭证和源/目标端点保留在内存之外。通过这种方法，入侵者无法随时访问服务凭证或目标端点。
缓存：云原生应用程序需要扩展到多个实例，应用程序应使用外部缓存，例如Memcache或Redis。为了支持无状态设计，应用程序不应该在请求执行时间内存储任何信息。
个人识别信息：切勿将PII信息写入日志。日志流相对不安全并且包含纯文本信息。日志流通常是入侵者的软目标。
加密静止和传输中的数据：这不仅适用于云应用程序，还适用于数据中心。敏感数据在通过网络旅行时或在仓库中休息时应加密。 IPSec和SSL / TLS可以方便地对流经不同网络的数据进行加密。
加密资源：您的加密资源具有流动性和动态性，并且必须定期进行循环或续订。应用程序，文件或数据库字段级别的加密通常提供最高级别的安全性。但是，应用程序很多都使用分散加密和解密方法。这不仅提供了更好的性能，而且还减少了故障点。
云安全是一项共同的责任。云供应商（包括IaaS和PaaS）管理云的安全性，但客户有责任在云中保护其应用。为了充分保护他们的数据，企业架构师和技术团队应该应用最佳实践和设计方法，以保持应用程序和数据的安全。云中的应用程序和数据安全已经出现了一些最佳实践，并且它们将继续发展。安全实施不能是事后考虑，并且在设计级别实施安全实施将有助于保护托管给组织的机密数据并保持合规性。
↓↓↓ 点击"阅读原文" 【加入云技术社区】
相关阅读：
Gartner：2018 年 公有云IaaS魔力象限出炉，大量公司消失了。。。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK