深圳东风大厦 网站建设,做电影网站犯罪吗,wordpress文章添加媒体,齐齐哈尔市建设局网站参考链接#xff1a; 微服务介绍
在整体式架构中#xff0c;由于运行应用程序的运行时环境相对隔离#xff0c;所以治理和安全保护很简单。微服务架构具有典型的革新特征#xff0c;给活动的治理和应用程序的安全威胁保护带来了更多挑战。 微服务架构中的安全性
微服务…参考链接 微服务介绍
在整体式架构中由于运行应用程序的运行时环境相对隔离所以治理和安全保护很简单。微服务架构具有典型的革新特征给活动的治理和应用程序的安全威胁保护带来了更多挑战。 微服务架构中的安全性
微服务架构通过定义分布式特征来获得灵活性系统中的服务能够以分散方式独立开发和部署。从安全角度讲这种开放架构的一个缺陷是系统现在更脆弱因为攻击面增加了。开放的端口更多API 是公开的而且安全保护变得更复杂因为需要在多个位置执行安全保护。本节将简要介绍在设计受微服务启发的系统时要考虑的一些安全方面。 身份验证和授权
身份验证和授权是两个核心流程在尝试与 IT 系统交互时通常涉及这两个流程。这些核心流程可以确保系统面对攻击时的安全性
身份验证是确认系统项目干系人具有他们声明的身份的过程。在人类世界项目干系人通常通过提供用户名和密码对来进行身份验证。有一些先进、复杂的机制可用来执行身份验证这些机制可能包括生物特征身份验证、多因素身份验证等。被验证的对象人或特定的子系统通常被称为主体。
授权机制用于确定允许一个主体在系统上执行哪些操作或者主体可访问哪些资源。授权流程通常在身份验证流程后触发。通常当主体通过身份验证后会提供主体的信息来帮助确定该主体能够和不能执行哪些操作。 在整体式应用程序中身份验证和授权简单而又普通因为它们由应用程序实际处理不需要拥有高级机制来提供更安全的用户体验。但是在具有典型的分布式特征的微服务架构中必须采用更高级的模式来避免提供凭证的服务调用之间的反复拦截。您希望一次可以验证主体的一个身份。这个身份简化了身份验证和授权流程利用了自动化功能并提高了可扩展性。
避免冗余地提供用户名和密码的一个著名解决方案是使用单点登录 (SSO) 方法。一些流行的 SSO 实现提供了这项功能。示例包括 OpenID Connect、SAML、OAuth2 等。每种实现适合一种特定的业务用例。表 1 对比了这些方法。 表 1 对比 SAML、OpenID Connect 和 OAuth
考虑因素SAMLOpenID ConnectOAuth2身份验证 是 是 伪身份验证授权 是 否 是传输 HTTP Redirect (GET)绑定、SAML SOAP 绑定、HTTP POST 绑定等 HTTP Get, Post HTTP令牌格式 XML JSON JSON 或 SAML2安全隐患XML Signature Wrapping to impersonate any user网络钓鱼。 OAuth 2.0 不支持签名加密渠道绑定或客户端验证。 相反它完全依赖于TLS保密。网络钓鱼。 OAuth 2.0 不支持签名加密渠道绑定或客户端验证。 相反它完全依赖于TLS保密。最佳用途企业 SSO 难以采用移动平台SSO 为公众消费者应用API 授权
在微服务架构中应用 SSO 时需要考虑的一种技术是创建一个 SSO 网关并将它放在服务与身份提供者之间。然后该网关可代为处理从系统传到外部和从外部传到系统的身份验证和授权流量。此技术可帮助避免每个微服务都需要与同一个身份提供者单独握手的情形从而消除了冗余的流量。此技术的一个缺点是与网关建立了额外的关联这违背了微服务架构的演化原则。 服务间身份验证和授权
在为微服务架构建立安全策略时可以考虑以下服务间身份验证和授权实践
信任边界 一种选择可能是隐式地信任在一个已知、隔离的边界内的服务之间发出的所有调用。此技术初看起来像是不安全因为存在受到典型中间人攻击的风险。但实际上随着专为微服务设计的成熟工具和技术的出现此技术变得更加合理。
您可以使用容器化技术比如 Docker来降低风险。Docker 提供的许多功能使开发人员能在不同层面灵活地、最大限度地提高微服务和整个应用程序的安全性。在构建服务代码时开发人员可以自由使用渗透测试工具对构建周期的任何部分执行压力测试。因为构建 Docker 镜像的源代码已在 Docker 分布组件Docker 和 Docker Compose 文件中明确地以声明形式进行了描述所以开发人员可以轻松地处理镜像供应链并在需要时执行安全策略。此外能够通过将服务放入 Docker 容器中来轻松加固服务使它们不可变从而给服务增添强大的安全保障。
通过采用软件定义基础架构可以使用脚本语言快速创建和配置私有网络而且可以在网络级别上执行强大的安全策略。来自 HashiCorp 的 Terraform® 是脚本语言的一个良好示例该语言可帮助您从虚拟机、网络等不同层级快速创建整个基础架构。
利用 SSO 如果您已经使用 SSO 模式作为 IT 系统的身份验证和授权模式那么此过程会很简单。可将 SSO 用于微服务架构中的服务之间的内部交互。此方法可使用现有的基础架构也可简化对服务的访问控制将所有访问控制操作都集中在一个企业访问目录服务器中。
基于 HTTP 的哈希运算消息验证码 (HMAC) 一种常用的服务间身份验证模式是基于 HTTP 的基本身份验证。它之所以得到普遍使用是因为它非常简单、是轻量的且成本很低。但是它的一个缺点是如果将它与简单的 HTTP 结合使用则存在着凭证被轻松”嗅探”的风险。通过在服务间的每次交互中使用 HTTPS可以减轻这些风险。但是仅使用 HTTPS 的方法会增添大量的流量和证书管理开销。HMAC 可能是用来取代基本身份验证的候选方案。
在 HMAC 中请求内容与一个私钥一起执行哈希运算将得到的哈希值与请求一起发送。然后通信的另一端使用它的私钥副本和收到的请求内容来重新创建哈希值。如果哈希值匹配则允许请求通过。如果请求已被篡改则哈希值不匹配另一端就会知道并做出适当的反应。
使用特殊用途服务管理密钥 要消除微服务架构等分布式模型中的凭证管理开销并从所构建系统的高安全性中获益一种选择是使用一个综合性密钥管理工具。此工具允许存储、动态地租用、更新和撤销密钥例如密码、API 密钥和证书。由于微服务中规定的自动化原则这些操作在微服务中非常重要。市场中已有一些项目拥有这个领域的功能Vault来自 HashiCorp或 Keywhiz来自 Square是两个例子。
混淆代理问题 当一个服务客户端尝试调用另一个服务服务器时在完成身份验证后客户端开始在请求后从服务器收到信息。但是为了满足来自客户端的请求服务器通常需要与其他下游服务建立其他连接以获取服务器没有的其他信息。在这种情况下服务器会代表客户端尝试访问下游服务的信息。如果下游服务允许访问不允许客户端拥有的信息这就称为混淆代理问题。
您需要了解这种情况并拥有克服混淆代理问题的对策。一个解决方案可能是安全地分发一个综合令牌该令牌可以帮助识别客户端又可以用它来进一步了解客户端有权访问哪些资源并接受流量开销。 数据安全
数据被视为 IT 系统中最重要的资产尤其是敏感数据。各种各样的机制可用于保护安全信息。
但是无论选择哪种方法一定要考虑以下一般性的数据安全准则
使用著名的数据加密机制 尽管从理论上讲不存在无法攻破的数据加密方法但仍然存在一些成熟的、经过检验的、常用的机制比如 AES-128 或 AES-256 等。在进行安全考虑时使用这些机制而不是在内部创建自己的方法。另外及时更新和修补用于实现这些机制的库。
使用一个综合性工具来管理密钥 如果您的密钥未得到妥善管理您为数据加密投入的所有努力都会白费。首要做法是不将密钥和数据存储在同一个位置。另外不要让密钥管理复杂性违背微服务架构的灵活性原则。尝试使用具有微服务设计思路的综合性工具这种工具不会破坏您的连续集成和连续交付管道。来自 HashiCorp 的 Vault 或 Amazon Key Management Service 是”微服务友好的”密钥管理工具的例子。
针对业务需求来调整安全策略 安全性是有代价的。不要加密所有数据仅将精力放在最宝贵或最敏感的数据上。根据业务需求来制定安全策略并不断调整策略因为战略目标可能不断改变解决方案中包含的技术也是如此。 深度防御
因为没有哪种解决方案能同时解决所有安全问题所以提高微服务架构安全性的最佳方法是结合使用所有成熟的技术。更重要的是将它们应用于架构的不同层级。
除了身份验证、授权和数据安全之外还可以考虑以下技术来提供进一步保护
设置防火墙 防火墙常用于对外监视阻止对系统的不良意图的尝试。如果使用得当防火墙可过滤掉大量恶意攻击最大限度减少要在系统内的下游层级上完成的工作。防火墙还可以放在不同层级上。一种常用的模式是在系统边缘设置一个防火墙然后在每个主机本地设置一个防火墙。考虑到每个主机一个服务的模型的快速普及这可能成为微服务的运行时环境。您可以进一步定义一些 IP 表规则以便仅允许已知 IP 范围的用户访问主机。借助防火墙您可以执行一些安全措施比如访问控制、速率限制、HTTPS 终止等。
网络隔离 微服务架构的分布式特性带来了一些安全挑战。但是每个服务的细粒度和高度针对性的特征意味着您可以轻松地将微服务放在网络中的不同隔离网段中从而控制它们之间的交互。通过采用云技术和软件定义基础架构网络隔离想法更容易实现因为可以轻松地脚本化和自动化该过程。OpenStack 技术拥有一个名为 Neutron 的综合性网络技术栈。此技术栈允许您快速配置虚拟私有网络将虚拟服务器放在不同的子网中可配置这些子网以您想要的方式让它们进行交互。您可以在分开的私有网络上实施安全策略使用新兴的工具比如 Terraform通过脚本来加强服务安全性。
容器化服务 一种在微服务构建过程中被广泛采用的领先实践是采用不可变基础架构。要实现此目的可利用 Docker 等技术来容器化您的服务。每个微服务都可以部署到一个单独的 Docker 容器中从而在每个服务中详细地执行安全策略。这使得整个容器不可变就像创建了一个加固的只读部署单元一样。可以将特定服务部署的每个基本映像放入扫描过程中以便在较低的级别上保证服务的运行时环境的安全。 微服务架构中的治理
一般而言治理活动指的是规定微服务架构中的服务如何协同实现构建系统的战略目标并付诸于行动。基于微服务的系统中缺乏对服务的严谨治理这使得微服务计划很快偏离了正确方向。软件开发中的两种常用治理方法是
设计时治理根据一组通用的策略和标准来定义和控制软件组件的创建包括组件的 设计和实现
运行时治理在运行时的执行过程中实施组件策略 在微服务架构中服务是独立构建和部署的。它们是高度解耦的服务可能是使用各种不同的技术和平台构建的。因此从理论上讲不必为服务设计和开发定义一种通用标准因为每个服务能够以不同方式构建只要它能履行自己的专门职责。微服务架构意味着只能使用去中心化的运行时治理功能。服务必须与它们负责的业务能力明确一致服务不得尝试执行其上下文边界外的操作。否则会让服务位于一个紧密耦合的架构中导致交付熵值 (delivery entropy) 混乱和内聚混乱 (cohesion chaos)。
微服务架构的运行时治理中的一些常用概念可能是监视、服务发现、通用安全要求等。 案例分析
第 6部分小节”实际示例创建新微服务”中已创建新的 Search Catalog 和演化后的 Accounts 微服务。现在您可以执行其他更改以便在一个安全环境中将整体式 Orders 系统与新微服务集成。
在整体式应用程序示例中身份验证流程是使用基本身份验证方法来完成的也就是说将凭证与关系数据库中存储的用户名和密码进行比较验证。执行身份验证后用户能看到应用程序的所有选项。
我们来回顾一下以下是该系统的 3 个主要部分它们分别被描述为所拥有的数据类型、允许不允许谁查看该数据以及如何保护该数据
Catalog Search 微服务 Catalog Search 微服务拥有产品的所有信息。此信息可供任何人查看所以 API 不需要身份验证。用户无需登录即可查看该目录该目录也是在 HTTP 中公开的以便允许缓存信息来加快交互速度。因此对于这个微服务没必要执行更改。在未来您可能会使用 API 管理解决方案根据一种受控且安全的策略来向其他公司公开 Catalog API。
Accounts 微服务 这个微服务拥有客户的所有信息此信息是每个客户私有的。对于此微服务必须保护信息以保证只有经过验证的用户能看到和更新他们自己的信息。
Orders 整体式系统 Orders 整体式系统必须与其他微服务集成。您必须确保只有经过验证的用户才能创建和查看他们的订单而且不允许创建或查看其他用户的订单。
基于这个回顾可以看到您必须保护两个组件。为此创建一个 SSO 网关使用整体式应用程序中使用的身份验证方法来验证用户配置 Accounts 和 Orders 微服务以便只允许使用来自此单点登录帐户的调用。首先在可以使用此 SSO 网关安全地连接的云环境中内将整体式应用程序的 Orders 方法公开为 API。为此使用创建的同一个 Secure Gateway 来连接整体式系统的 DB2 和 IBM Bluemix 中的 API Connect 服务。 集成和保护整体式系统
要集成整体式应用程序的服务需要建立一条从 Bluemix 到企业内部数据中心的安全连接然后创建一个 API 网关在 Bluemix 内安全地提供服务。 连接到整体式应用程序的服务
在”企业内部数据库连接”中您在 Bluemix 中创建了一个 Secure Gateway 服务并配置了一个与 DB2 数据库具有安全连接的目标。现在可以执行以下步骤配置另一个目标来连接到整体式 Orders 应用程序所公开的 REST 服务
使用您的 IBM id 登录到 IBM Bluemix。
创建一个新目标 A.在 Bluemix 控制台中单击您的 Secure Gateway 服务转到仪表板。 B.在 Secure Gateway 仪表板中单击创建来连接企业内部数据中心的网关参见企业内部数据库连接。 C.单击 Add Destination。 D.Add Destination Wizard 中选择 On-Premises 并单击 Next。 E.输入您想连接的资源的主机名或 IP 地址和端口在本例中为整体式应用程序部署到的应用服务器的本地 IP 地址或主机名。 F.选择 HTTPS 或 HTTP 作为连接服务的协议。单击 Next。 G.选择 Mutual Auth 作为身份验证方法并为证书选择 Auto-generate 选项。单击 Next。 此选项可确保在连接的客户端与 Secure Gateway 客户端之间执行安全身份验证。借助此选项您可以控制哪些客户端可连接后端服务方法是向它们提s供使用传输层安全 (TLS) 相互身份验证所生成的证书。 H.将 IP 表规则留空。单击 Next。 在此选项中还可以创建规则来仅允许来自已知 IP 地址的连接例如来自开发和质量保证团队的 IP 地址。在这种情况下还必须配置第 g 步中生成的证书。 I.输入您想为目标使用的名称在本例中为 Orders Monolith然后单击 Finish。 图 1 中显示了该整体式应用程序的网关窗口。Orders Monolith 目标显示了一个较小的红色手形图标位于磁贴右上角表明访问被访问控制表阻止。 图 1.包含数据库和服务目标的 Secure Gateway 仪表板 J. Orders Monolith 目标窗口如图 2 所示显示了用于连接企业内部的 REST 服务的云主机和端口。单击 Download Authentication Files证书并将它们保存到本地文件夹中。
图 2. 后端服务目标信息
K.在网关客户端控制台中输入以下命令来配置访问控制表 (ACL)以便允许流量进入企业内部数据库
1 acl allow services ip address or hostname:port 对于此示例使用的命令为
1 acl allow orders.xxxx.net:80
创建一个密钥库和信任库来使用生成的证书 A. 打开一个 SSH 或 Telnet 客户端。 B. 要为客户端创建密钥库可在所下载证书的解压目录中输入以下命令 openssl pkcs12 -export -out sg_key.p12 -in JDR26UI0ab1_iIh_destCert.pem -inkey JDR26UI0ab1_iIh_destKey.pem -password pass:a password -name BmxCliCert -noiter
现在您已拥有密钥库 sg_key.p12可以使用它执行相互身份验证。 C. 要创建一个包含所有服务器和 CA 证书的信任库可在所下载证书的解压目录中发出以下命令 keytool -import -alias PrimaryCA -file DigiCertCA2.pem -storepass password -keystore sg_trust.jks (answer yes to trust it) keytool -import -alias SecondaryCA -file DigiCertTrustedRoot.pem -storepass password -keystore sg_trust.jks keytool -import -alias GtwServ -file secureGatewayCert.pem -storepass password -keystore sg_trust.jks keytool -importkeystore -srckeystore sg_trust.jks -srcstoretype JKS -deststoretype PKCS12 -destkeystore key_trust_store.p12 (enter a password for the trustore, repeat the password and leave empty the source password)
现在您拥有 sg_trust.jks 和 key_trust_store.p12 文件可使用它们执行相互身份验证。 在云环境中将整体式服务公开为 API
在”连接整体式应用程序的服务”中您在 Bluemix 与企业内部的整体式应用程序的服务之间建立了安全连接。现在可以使用 API Connect Bluemix 服务将后端服务公开为 API以便在您的 Bluemix 空间内轻松使用它。
使用您的 IBM id 登录到 IBM Bluemix。
创建 API Connect 服务 a. 转到 Bluemix 目录。 b. 在 APIs 类别中选择 API Connect service。 c. 单击 Create。
配置一个 TLS 配置文件以便向 Secure Gateway 客户端执行身份验证 a. 在 API Connect 仪表板中单击左上角的 Navigation to 图标然后单击 Admin图 3。 图 3. API Connect 上的 Navigation To 图标 b. 单击顶部菜单中的 TLS Profiles然后单击 Add。
c. 输入您的 TLS 配置文件的名称和描述。
d. 单击仪表板右上角的 Save 选项保存该配置文件。
e. 单击 Present Certificate 选项旁边的加号 ()。
f. 单击 Select File 并搜索第 b 步中生成的 sg_key.p12 文件。
g. 输入您在创建 sg_key.p12 文件时配置的密码第 b 步。
h. 单击 Upload。
i. 通过将 Request and validate the certificate against the supplied CAs in the truststore 滑块滑动到 On 位置验证该证书。
j.单击 Save。
k.单击 Trust Store 选项旁边的加号 ()。
l.单击 Select File 并搜索第 c 步中生成的 key_trust_store.p12 文件。
m. 输入您在创建 key_trust_store.p12 文件时提供的密码。
n. 单击 Upload。
您的 TLS 配置文件现在类似于图 4 中的配置文件。
图 4. API Connect 的 TLS 配置文件配置 使用启用了相互身份验证的 Secure Gateway 云主机创建整体式服务 API a. 转到 API Connect 仪表板。 b. 在 API Connect 仪表板中单击左上角的 Navigation to 图标然后单击 Drafts。 c. 单击 APIs。 d. 单击 Add →New API。 e. 输入 API 标题选择 Add to a new product输入新产品标题然后单击 Add。 f. 在 Design API 选项中输入联系人、条款和许可以及外部文档等一般信息。 g. 在 Schemes 字段中选择 HTTP。 h. 在 Host 字段中输入 Secure Gateway 所提供的云主机:端口。 i. 输入整体式服务的基础路径。在此示例中该路径为/CustomerOrderServicesWeb/jaxrs/ j.选择服务返回的数据类型在本例中为 application/json。 k.在 Security Definitions 选项中保持 clientID (API Key) 选项不变。 l.在 Security 中选择选项 1 clientID (API Key)。 m. 在 Paths 选项中输入服务路径在本例中为 /customer/openorder然后单击 add 操作并选择 POST。 n. 对于 Parameters 选项选择您想发送到您的服务的信息在本例中为以下信息
ID 要创建的订单的 ID
Date 订单日期
Line Item 包含要加入订单的产品的 JSON 对象
Total 产品价格 o. 返回到 API 仪表板并选择 Drafts and the products。 p. 选择第 e 步中创建的产品。 q.选择您想要对此 API 使用的选项在本例中为以下信息
Visibility Authenticated users
Subscribable by Authenticated users r.单击窗口右上角的 Stage然后选择您希望将 API 发布到的目录。 s. 在 Products 选项卡上单击临时存储产品右侧的 3 个点然后单击 Publish。在 Edit visibility 中为两个选项都选择 Authenticated Users然后单击 Publish。 t. 在 API Connect 仪表板上选择临时存储 API 的目录单击 Developers 选项卡然后单击 Add Bluemix Organization。 u. 输入使用此目录中公开的 API 的用户的电子邮箱。 v. 单击 API Connect 发送的电子邮件中的链接以接受使用该 API 的邀请。 w. 选择您想在哪个组织中使用该 API。 现在您可通过这个私有 API 来使用您的整体式应用程序创建订单。 创建 SSO 网关
现在您已与该整体式应用程序建立安全连接并将它的 API 公开为 Bluemix Organization 内的私有服务。您可以创建 SSO 服务来验证用户然后代表用户调用 Orders API 和 Account 微服务。
最终架构
图 5 给出了最终的应用程序架构。 图 5 安全的架构
