全部展开 全部收起
概述
您用于构建应用的编程语言和框架决定着您能否成功交付和长期维护应用。选择何等语言和框架,对扩展业务、运行应用以及为客户交付高质量功能有着长远的影响。通常而言,更换语言或框架会消耗巨额成本。但是,盲目追求多种并行的生态系统(即多种语言和框架)也会导致复杂性升高,敏捷性下降。
语言和框架的选择会影响诸多因素,包括交付速度、现有生态系统的稳定性和优势、运营准备情况和生产绩效。尽可能使用低代码平台,这样您就可以专注于解决业务问题,无需分心应对传统开发过程中的复杂性。如果您的应用需求复杂程度较高,可选择成熟的语言和轻量级框架。
原则详细信息
相比传统的手动编码方式,低代码平台可帮助您更快地构建、测试和部署企业应用。它们不仅非常适合您与企业利益相关者合作构建临时应用,适合构建报告和分析应用,低代码平台还可帮助您扩展 SaaS 应用以及对原有应用进行现代化改造。使用低代码方法,您可以消除复杂性,轻松添加添加新功能,例如数据可视化、数据收集、数据分析、安全性、可访问性、性能和全球化。得益于大大降低复杂性,低代码平台可以大幅减少代码维护工作。
但是,如果您的应用需求复杂程度较高,请选择使用成熟的编程语言和轻量级框架。在选择编程语言时,尽量选择具备以下关键优势的语言:
较新的语言的语言设计以及相应的生态系统和库往往具有更高的变动率。这意味着更加难以评估风险,后续更改的成本也更高。
在选择框架时,尽量选择开源框架。开源框架经历了同行的持续检验,吸取众多开发人员的创建和维护经验构建而成,其功能符合大多数开发人员的需求和预期。您可快速发现并修复漏洞。此外,您还需要选择占用资源(如 CPU、内存、网络带宽或文件句柄)较少的轻量级框架。
您所采用的应用框架应当能够在优化任务重点(业务逻辑优于样板和基架)和保持灵活性(支持您满足当前和未来的功能需求)之间取得平衡,并针对日志记录、遥测、安全、配置和通用模式(如构建 REST API)等常见功能提供易于使用、合理且无争议的默认值。
Oracle 建议
Oracle APEX 是一个低代码平台,它不仅提供丰富的高级组件,例如表单、图表和 UI 小部件,还提供通用设计模式和直观的图形开发环境。使用 APEX 开发的应用可以通过 SQL 访问本地数据,并使用 REST API 与外部服务集成。此外,您还可以将您在 APEX 中开发的功能发布为 REST API 以供外部使用。
如果低代码平台不适合您的应用,您可以选择 Java 编程语言。Java 为常见的应用程序用例提供了一组稳定而广泛的功能,并拥有用于开发现代应用程序的受信任和稳定的库和框架的健康生态系统。Java 专注于简单性和可读性,并且精心支持开发人员工具(包括静态分析工具和测试框架),降低了软件维护成本以及生产应用中的错误风险。
使用 GraalVM 开发和运行应用。GraalVM 是一个 JDK 发行版,它能够通过动态运行时优化、主动且高频率的安全漏洞修补以及 Java Flight Recorder 等低成本的性能分析和诊断工具,同时提供 Java 的稳定性与强大性能。
请使用 Graal Development Kit for Micronaut 或 Helidon 框架,采用 API 优先方法来构建应用。这两种方法的基架可以极大地缩短应用交付时间,并针对常见使用场景(例如 REST API)提供简单易用的模式,为日志记录、遥测和存储等常见活动提供简单、无争议的框架选项。此外,它们还通过惯用响应式 API 支持非阻塞 I/O,可确保实现高性能服务;还支持高性能网络库,可实现低延迟。
Helidon 和 GDK 均内置支持 GraalVM 原生映像,可帮助您构建内存高效的应用和紧凑型应用。
概述
将应用功能或任务拆分成多个相互协作的独立松耦合服务。每项服务承担单一职责,专注于提供一项特性或功能。相比传统的一体化架构,此方法可改善应用维护、功能开发、测试、部署和可伸缩性。
采用合同优先的 REST API 设计方法提供清晰易懂的接口,用于支持各服务之间的通信。API 合同可为团队提供必要的协作和功能使用机制,无需依赖于服务实施的内部细节。例如,开发团队可以完全拥有一项服务,并自由改进实施,而无需与其他开发团队协调代码依赖关系。
原则详细信息
合同优先方法的第一步是指定服务的 REST API,然后对 API 实施进行原型设计,让利益相关方(如使用该服务的团队)进行试用。所有相关方都同意 API 的详细信息后,各团队就可以并行实施该服务以及其它使用该 API 的服务。
在产品生命周期早期定义安全和服务水平协议的政策执行,以确保所有利益相关方清楚了解服务合同的所有方面。
将 API 规范与代码一视同仁,使用版本控制系统管理 API 规范、源代码和策略配置。
Oracle 建议
使用与实施无关的 OpenAPI 格式指定 API,并将其存储在 Oracle Cloud Infrastructure (OCI) DevOps 提供的存储库中。
使用 Graal Development Kit for Micronaut 或 Helidon 等轻量级开源方法实施服务。
在 OCI Kubernetes Engine 或 Oracle Functions 等无服务器平台上部署服务,以简化部署、增强可扩展性和提高成本效益。
使用 Oracle Cloud Infrastructure API Gateway,基于 API 规范创建受保护和监管的私有或公有端点。
使用 Oracle Cloud Infrastructure Service Mesh 简化 OCI Kubernetes Engine 集群托管的服务之间的通信,确保通信安全。OCI Service Mesh 还支持您通过其(作为 sidecar 在应用云池中运行的)代理组件所发出的指标和日志来观测服务之间的所有网络流量。
概述
通过容器将代码及其依赖关系打包成一个单元,让应用可以在多个计算环境中快速、可靠地运行。您可通过执行容器镜像文件在计算环境中创建和启动容器。
与传统的虚拟机相比,容器更小,需要的资源更少,而且启动时间更快。它们独立于平台,可以在任何地方运行应用。为了利用这些优势,您需要将应用分解成多项服务(每项服务执行一个业务功能),并将每项服务打包成一个容器。对于传统应用,您可以将其中的现有功能逐步替换为容器化服务,直至整个应用被重构。
原则详细信息
将应用代码和依赖关系打包成一个可执行单元(容器镜像),赋予容器高度可移植性。通过将这种可移植性与基础设施的抽象性相结合,容器可为应用提供操作一致性。无论应用是在企业内部的物理服务器上运行,还是在云端的虚拟机上运行,它每次都会产生相同的结果。
通过这种一致的可重复性和可预测性,容器简化了 DevOps 流程,让您的开发团队能够更快地部署应用。此外,由于提供流程级的隔离且经常被替换,容器还简化并加快了与修复软件漏洞相关的流程。应用程序分解成模块化的容器化服务后会变得非常强大。单个服务中的错误或故障不会导致整个应用瘫痪,而且您可以单独更新或修补每项服务。
与虚拟机不同,容器内部并未随带操作系统,而是共享主机的操作系统。因此,容器的体积更小,启动速度比虚拟机快。大多数容器镜像的大小为几十兆字节,而虚拟机的大小为几千兆字节,其启动时间为几秒钟,而不是启动虚拟机所需的几分钟。
在容器中使用模块化服务运行和扩展应用的理想方式是在每个容器中只部署一个服务。这种方法将服务相互隔离,从而消除了停机时间,并使每个服务能够独立扩展。
尽管您可以手动部署容器,但最好使用与连续集成工具和连续部署工具相集成的容器管理软件。
Oracle 建议
使用 Oracle Cloud Infrastructure Registry(即 Container Registry)来存储您的容器镜像,使用 Oracle Cloud Infrastructure Kubernetes Engine 来运行和管理容器。这些全托管式服务与 OCI 平台功能紧密集成,在所有 Oracle Cloud 区域可用,满足 PCI、ISO、SOC、HIPAA 和 FedRAMP 等监管要求。
除了在 Container Registry 存储容器映像之外,您还可以存储清单列表(有时称为多架构映像)以支持多种架构,例如 ARM 和 AMD64。为了识别和减少潜在的安全漏洞,可以对上传到 Container Registry 的所有镜像启用镜像扫描。您还应该对容器镜像进行签名,以确保只有经过授权和信任的镜像被部署到 OKE。
概述
持续集成 (CI) 和持续部署 (CD) 是一套工具和程序,可供开发团队频繁、可靠地交付代码变更。CI/CD 优秀实践包括代码审查,以及对单元测试、集成测试、代码签到、提交票据和将应用部署到开发和测试环境的指导。
持续集成是一种软件开发实践,指开发人员频繁将代码变更集成到共享信息库主干。每次集成都通过创建构建,然后对构建运行自动测试来验证开发人员变更,从而确保您的应用不会在新变更集成到主干时发生中断。
持续集成的优势包括:
持续交付是在持续集成的基础上,将通过相应测试的构建自动交付至测试和/或生产环境,目的是让代码库随时准备好部署至客户生产环境。
持续交付的其它优势包括:
持续部署比持续交付更进一步,它可将每一项通过所有测试的变更自动部署到客户生产环境,而无需人工干预。未通过测试的新变更将无法部署到生产环境。由于无需人工干预,因此持续部署高度依赖于设计良好的测试自动化。
持续部署的其它优势包括:
CI/CD 提供了存储、集成、部署和维护代码的优秀实践,可自动化构建应用。这些优秀实践包括:
Oracle 建议
使用 DevOps 服务自动部署您的云原生应用。首先,将代码存储在 DevOps 代码库中并创建一个发布分支。以小批量的方式对发布分支进行修改,并每天协调分支中的问题以保持其稳定性。然后,使用代码库中的触发器功能来自动启动 DevOps 构建管道。
使用一个 DevOps 构建管道来构建与代码库相关的所有构件。如果构建失败,配置构建管道,使其在完成之前等待批准。批准请求应该交给触发构建的提交者,他们应该提交新的代码来解决这个问题,然后批准构建完成。对于成功的构建,配置构建管道以自动交付构件到 Oracle Cloud Infrastructure Artifacts Registry 服务,并自动触发 DevOps 部署管道。
在 OCI DevOps 构建管道的构建阶段,添加应用依赖项管理来检测应用依赖项中的安全漏洞 (CVE)。通过这种方法,您将能够在发现潜在 CVE 后立即进行检测和补救。
使用 Resource Manager 在一个最大安全区域内创建您的所有基础设施环境,自动获得部署安全性优势。通过使用 Resource Manager,您可以使用基础设施作为代码,以一致的方式在所有区域内自动创建基础设施。然后,您可以配置 DevOps 部署管道,使其始终部署到您在安全区创建的资源。
创建一个单一的 DevOps 部署管道,部署从单一构建管道创建的所有构建。组织部署环境,例如 OCI 区域、可用性域和故障域。使用金丝雀、滚动或蓝绿部署策略来配置管道。您也可以将管道配置为自动触发测试。启用 OCI Monitoring 和 Application Performance Monitoring 来检测应用和基础设施问题。
如果没有检测到问题并且测试成功完成,配置部署管道以自动将工件部署到部署策略中的下一个环境,直到构件完全部署到所有生产环境。当部署到生产环境时,配置该管道以一次部署到可用性域中的所有故障域。一次部署到一个区域中的所有可用性域中,然后再一次部署到所有区域。继续在应用和基础设施上使用 OCI Monitoring 和 Application Performance Monitoring,以快速检测问题。设置预警,如果任何关键指标在部署过程中突然下降,自动认定部署失败并触发回滚到前一个版本。
概述
托管服务可提供特定功能,且无需您执行优化性能、可用性、扩展、安全性或升级等维护任务。借助托管服务,您可以集中精力为客户提供出色功能,而不必担心运营复杂性。
托管 OCI 服务可为云原生开发提供可扩展、安全的组件。您可以使用托管服务来开发和运行应用并存储数据;即便不具备专业知识,您也可以使用同类优秀的解决方案来构建和运行应用。
原则详细信息
借助托管服务,您可以创建高度可用、可扩展、敏捷且高性能的应用,同时实现安全性、合规性和弹性。
托管服务降低了应用底层组件的复杂性,可助您轻松存储和检索数据以及创建和运行应用。这些服务还集成了支持自动构建、测试和部署应用的工具集,可助您提高工作效率并加快产品上市速度。
托管服务可集中并自动化执行各种基础设施管理任务,从而消除人为错误和专业技能需求。底层基础设施将及时更新,安全性高,您可以监视和跟踪修改或访问,以保障应用和数据的机密性和完整性。
托管服务提供高可用性和可扩展性,可以轻松满足您的应用需求,并且您只需按使用付费。您可以先从小规模开始部署,然后按需扩展,且性能或可靠性不会出现任何下降。
Oracle 建议
我们建议采用以下云技术服务:
这些服务均具备高水平的可用性、性能和弹性。其底层基础设施由 Oracle 进行管理和修补,可确保您的应用始终处于安全状态。
概述
应用状态包含许多元素,包括数据缓存、用户偏好、个性化、服务之间交换的信息、多步骤工作流程中的位置、应用部署、运行时配置以及用户会话(例如,用户上次访问的页面或者用户购物车规模和其中的商品)。如果应用状态丢失,则可能会导致数据丢失、应用故障、用户体验欠佳,有时还会造成应用完全停机。
如果将应用状态存储在本地文件系统或单个主机的内存中,一旦应用发生故障(例如重启或本地化磁盘故障),应用状态就可能丢失。解决方法就是将状态保存在外部持久性存储中。但为了确保数据一致性,您需要使用尽可能少的持久性存储,最好是仅使用一个持久性存储。
原则详细信息
应用状态的元素通常存储为各种格式的多个构件,例如序列化对象、JSON 或 XML 文档或文本文件。如果这些元素存储在多个持久性存储(例如外部文件系统、消息存储、对象存储、多个数据库或弹性块存储)中,则不同数据存储可能会不同步,从而导致状态不一致。应用还必须实施事务、联接和幂等性策略,从而确保在需要以单元形式更新状态时提供数据一致性。
将应用状态元素分散到多个存储中会导致安全漏洞几率增加。生命周期操作,例如添加和删除节点、打补丁、备份和恢复以及灾难恢复复制非常复杂,并且需要特别注意,以确保不同门店的状态保持一致。
因此,最好能够将所有应用状态和数据存储在一个数据库中。数据能够在单个存储中保持一致,并更容易管理。使用此方法可以替换应用实例。这尤其有利于弹性微服务或临时实例等现代应用架构,其中一个实例仅为单个或几个请求提供服务。添加节点是简化操作,因为新节点可以获取状态的最新副本并删除节点不会完全丢失状态。只需替换可执行文件,就可以以滚动方式应用补丁程序。节点可以从备份中恢复,并从数据库中获取状态。状态可以作为一个单元持续地复制到不同的区域,以便用于灾难恢复。不同区域保持一致状态可以确保故障转移或切换后应用不会出现任何功能问题。
Oracle 建议
如果您的应用使用数据库,那么请使用一个数据库来存储应用状态。相比其它选项(如文件或内存中表示),数据库可提供更高的可用性、完整性和安全性。理想方式是使用可以存储不同格式的多模型数据库来存储应用状态的所有元素。相比使用多个专用数据存储,多模型数据库可以轻松实现和维护所有应用状态元素的一致性。(注意:尽管在应用程序中存储缓存状态是允许的,但应用程序必须被设计成使用数据库作为真理的来源,并能够从数据库中重新创建其状态。)Oracle Database 是实现这一目的的理想选择。它可以存储不同的格式,并提供可预测的性能,因此将应用状态存储在其中并不会降低应用性能。
对于未使用数据库的应用,请考虑使用 Oracle Cloud Infrastructure Object Storage 等其它持久性存储来存储状态。如果应用状态不能保存在单个数据存储中,请将应用状态存储在可以在发生故障后保持同步并恢复为一致单元的多个数据存储中。
下面是有关在 Oracle Database 中存储状态的一些建议。
概述
您的应用可能会使用多种格式的数据,例如表格(关系)、非结构化、XML、JSON、空间或图形数据。通常每种数据格式都需要不同类型的数据库。例如:关系数据库用于存储关系数据,文档存储用于存储非结构化数据,图形数据库用于存储分层链接数据。但是,使用多个数据库通常会导致操作复杂度增加和数据不一致。因此,理想方式是使用一个多模型数据库来存储、索引和搜索多种类型和格式的数据。
利用数据库功能简化应用逻辑。例如,将 SQL 用于查询、联接和分析;使用事务处理来确保一致性和隔离;使用内置的机器学习算法和分析功能来避免不必要的数据传输。要保护敏感数据,请使用数据库的安全功能和访问控制,并使用复制来提高应用的可用性、可扩展性和弹性。
原则详细信息
使用多模型数据库存储不同类型的数据,例如 JSON 文档、属性图形和关系数据。高级多模型数据库可全面支持数据库中存储的任何类型的数据。您可以存储新的 JSON 文档、插入关系行并更新同一 ACID 事务处理内的所有属性图。可以使用 SQL 语句来联接、筛选和聚合这些不同类型的数据,这可以保证您习惯于关系数据库的一致性和并发性。除了提供这些丰富的功能之外,多模型数据库还可以用作单用途数据存储,您可以使用 SQL 之外的 API(例如 REST API、文档存储 API 和图形 API)访问这些数据库。
使用多模型数据库的一个关键优点是可重用性。尽管数据可能具有不同的类型和配置,但管理这些数据的底层技术是一样的。这意味着,您不必学习多种数据库技术,也不必了解如何针对每种数据使用和优化数据库技术。由于技术是不变的,您也不必重写应用代码。此外,多模型数据库还可以减少数据碎片,提高应用弹性,更轻松地进行备份和恢复。
Oracle 建议
使用多模型融合数据库 — Oracle Autonomous Database 存储、管理和分析所有数据。使用视图在表中显示数据,轻松维护应用,在不影响现有应用的情况下更改基础 schema。使用基于版本的重新定义,让您无需停机即可升级应用。使用 Oracle Data Safe 实施和评估安全控制、屏蔽敏感数据和审计数据访问。使用 Oracle Data Guard 作为高度可扩展的数据读取高速缓存,确保灾难恢复备份一致。
Oracle Autonomous Database 执行运营任务时不会影响或中断工作负载。这意味着您不需要在应用中添加复杂的补偿逻辑来处理扩展或故障转移场景。数据库独立管理 CPU 和存储等资源,并提供弹性和双向可扩展性。
概述
单一用户请求可以追踪构成现代应用的多个服务或微服务的复杂路径。端到端跟踪是指追踪每个请求从来源传输至基础设施内部的路径,并帮助您从根本上解决问题。Monitoring 通常用作诊断工具,以便在应用无法正常运行时提醒开发人员。
开发人员、管理员和安全官必须保持权威并及时了解应用的运行状况、性能、运行状态和可能发生的安全事件,以确保应用的功能和性能在其生命周期中满足预期要求,并简化事件诊断和应用恢复。全面的端到端监视和跟踪应当能够直接实施和管理,而不会增加应用复杂性。
原则详细信息
应用可能无法按预期方式运行。例如,可能性能不佳或者彻底无法运行。不同于传统单体应用,基于微服务构建的应用会因组件之间的多种交互而带来更多的诊断挑战。
跟踪可以帮助您快速了解用户请求在通过微服务和基础设施等其它应用组件时的动态,也是查明问题最为行之有效的方式。使用端到端跟踪收集每个用户请求的数据,然后检查数据以确定您的应用可能遇到哪些瓶颈和延迟。例如,在履行之前,请求可能会通过多个微服务来回传递。如果无法跟踪请求的整个路径,则无法确定故障的根本原因。
Monitoring 通常更具针对性,可检测应用行为,然后收集、聚合和分析指标,从而帮助您增强对应用行为的了解。端到端监视还支持智能、自动化地与工具集成,以动态调整资源容量并协调应对意外事件。
清晰、准确、及时地了解应用运行状态和历史记录并不仅仅是为了衡量最终用户体验。您可能还需要遵守地区或国家的司法管辖权,能够生成关于处理特定敏感数据元素的详细活动报告或证明。
一般来说,监视解决方案应当能够兼容第三方工具,尤其是与您的环境管理工具保持一致。保持设计灵活性并避免供应商锁定十分重要。
Oracle 建议
从一开始就在应用中构建全面的监视和跟踪功能,并在整个生命周期中保持稳定一致。这些功能不应增加开发、测试和部署的复杂性,并且应易于部署和管理。尽可能采用可扩展的解决方案,以适应您当前使用和将来可能部署的多种平台。
OCI 服务(如 Monitoring)旨在提供开箱即用的监视支持。您还可以通过 API 和 SDK,利用一致的部署和管理经验将许多 OCI 服务扩展到您的应用组件。例如,您可以使用所有虚拟机和应用的集中存储来添加自动监视指标收集或日志捕获。
在开发和测试期间,您可以将服务配置为仅收集基本调试或性能测试信息。在进行生产部署时,再对现有配置参数进行简单更新以扩大信息收集范围,增强频率和可跟踪性。
Oracle Cloud Infrastructure Service Mesh 可自动捕获在 OCI Kubernetes Engine 中运行的服务的各种通信指标和日志。您可以使用这些数据来跟踪服务的运行状况并提高应用性能。
在整个云租户环境中使用强大的集中式数据收集,为分析、协调调查和警报生成提供单一信息源。Service Connector Hub 可以对事件提供灵活、一致和可定制的响应。OCI Logging Analytics 支持高效分析和调查您的所有云端(以及外部)事件日志系统。您还可以使用 OCI Service Connector Hub、Functions 和 Notifications,将摄取的指标和日志转换为切实可行的警报。您可以利用我们与第三方产品和服务(如 Splunk 和 Grafana)的集成。
以下 OCI 服务可帮助您整合应用托管环境中的日志、监视和跟踪:Logging、Monitoring、Logging Analytics、Application Performance Monitoring、OS Management、Database Management 和 Java Management Service。这些全托管服务与常见 OCI 基础设施资源实现了集成,并且提供支持机制来集成您的定制应用资源。
概述
单点故障是指应用中的某个组件发生故障,导致您的整个应用无法使用或出现性能波动。在开发具备高可用性和高可靠性的应用时,您可以使用自动数据复制来确保单一组件发生故障不会导致数据丢失。
通过跨计算机的数据复制以及冗余网络,您可以预防日常计算机和网络故障。在多个地理区域的数据中心(或“可用性域”)中复制数据可以有效防范局部灾难,例如火灾、地震、洪水或飓风。
原则详细信息
为了让应用实现高可用性,您需要确保在发生故障时,应用所依赖的数据仍然可用。实现数据高可用性的关键是通过自动数据复制实现冗余。
复制是指在分布式数据库系统的多个数据库中复制和维护数据库对象(如表)的过程。系统会先捕获一个站点的更改并存储在本地,然后转发并应用于其它远程位置的各个副本。
复制数据库可在两种不同的模式下运行:主动 - 被动和主动 - 主动。在主动 - 被动模式下,有一个主副本和一个或多个辅助副本,只有主副本参与应用数据处理。在主动 - 主动模式下,所有副本都参与数据处理。主动 - 主动模式不需要主辅助故障转移,因此可实现更高的资源利用率和可用性。
冗余可确保数据副本故障不会影响整体运行。计算机或磁盘故障通常是独立的,但网络或电源故障可能会导致一组计算机同时发生故障。为了防止发生此类事件,网络和电源基础设施应具有冗余性,并且数据副本必须小心放置在几个不会同时发生故障的位置。
Oracle 建议
OCI 数据中心经过精心设计,能够有效消除单点灾难性故障。典型的数据中心或可用性域包含多个称为容错域的独立故障单元。两个独立的容错域不能一起出故障。同样的,单个区域可能具有多个可用性域,这些可用性域在地理位置上是分开的,以确保其中两个可用性域不会同时发生故障。
使用 OCI 存储服务(如 Block Volumes、Object Storage 和 File Storage)在容错域和可用性域中复制数据,避免出现单点故障影响应用数据的可用性。利用 OCI Kubernetes Engine 充分发挥 OCI 中内置的弹性故障隔离优势,将应用部署在多个容错域和可用性域中。Oracle Autonomous Database、Data Guard 和 GoldenGate 提供双活软硬件复制,支持高可用性以及零停机打补丁和升级。您可以使用这些托管服务确保数据的高可用性,且无需构建和维护存储基础设施。
概述
纵深防御方法指实施多层独立、冗余的安全控制策略作为应用防御层。即使其中的某一个层发生故障,其它层仍然能够提供安全保障,例如,结合使用防火墙与入侵检测技术。
然而,无论是从局部还是整体来看,手动管理和配置安全控制策略都极为复杂、不透明且容易出错。所以最好能够使用自动化安全控制策略来保护您的应用和数据安全。
原则详细信息
使用涵盖物理、技术、管理、运营、人员和程序安全元素的各种控制措施实现纵深防御,有效管理风险。这些相互独立的控制措施组成了纵深防御,可有效应对故障、漏洞或其它安全风险。这些控制措施通过不同方式管理风险,并提供日志记录、审计和其它功能,能够检测到安全违规并将其报告给适当的利益相关者。
相比手动配置一组复杂的安全控制,我们建议您使用简单、规范的自动化控制来保护应用安全。自动化安全控制可消除导致许多安全事件的人为错误,您无需成为安全专家,也能够保护您的应用和数据安全。
Oracle 建议
在应用生命周期的所有阶段(包括开发、构建、测试、部署和运行时)实施简单易用的自动化安全控制。验证生命周期中每个步骤的用户、权限和访问策略,并确保仅在适当的时候授予访问权限。检测软件开发生命周期早期引入的安全问题。早期检测可确保应用在生产环境中使用安全架构优秀实践进行部署,并检测和缓解因配置错误或公开漏洞而导致的运营安全问题。
OCI 提供多重自动化安全服务来可靠保护您的应用和应用数据。下面是关于使用 OCI 服务的一些建议:
注:为免疑义,本网页所用以下术语专指以下含义: