◆ 众所周知,云计算架构通常分为三层,即基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),反映了云计算平台是在基础设施、平台及软件服务三个层面进行云化。

◆ 企业界率先提出了在云上设计应用程序的理念,使应用程序得以在云中以最佳的模式运行,以便充分发挥出云计算平台的弹性及分布式架构优势,这就是云原生(Cloud Native)架构。

◆ 云原生计算基金会(CNCF)对云原生给出的解释是:“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。”

◆ 安全是一个伴生技术,新技术必然会伴生新的安全问题。

◆ “容器不是轻量级的虚拟化,容器安全不是轻量级的虚拟化安全;虚拟化安全关注的是资源,云原生安全关注的是应用;安全左移是云原生安全的必经之路。

◆ 所谓安全左移,本质上是美国国防体系在21世纪初所提出的“软件确保”(Software Assurance)理念在云计算平台上的落地。

◆ 这在当下有一个时髦的词——内生安全,其核心是在软件开发阶段就需要注入安全的理念,不仅要确保软件的所有功能都是可预期的,还要努力做到不存在“可被利用的”漏洞。

◆ 谈到云原生,不能不提始终推动云原生发展的CNCF(Cloud Native Computing Foundation,云原生计算基金会)。

◆ 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

◆ 通过编排系统下载新镜像并启动相应的容器,并将旧的容器删除。这种只更新镜像而不改变容器运行时的模式称为不变的基础设施(immutable infrastructure)。

◆ 开发运营一体化(DevOps)是一组将软件开发和IT运营相结合的实践,目标在于缩短软件开发周期,并提供高质量软件的持续交付。与敏捷开发不同的是,DevOps更多的是在消除开发和运营侧的隔阂,聚焦于加速软件部署。

◆ 传统Web应用通常为单体应用系统,如使用WebSphere、WebLogic或.Net Framework等,从前端到中间件再到后端,各个组件一般集中式地部署在服务器上。后来随着Web Service标准的推出,应用以标准的服务交付,应用间通过远程服务调用(RPC)进行交互,形成了面向服务的架构(Service-Oriented Architecture,SOA),极大提升了应用组件的标准化程度和系统集成效率。

◆ 无服务(Serverless)是一种基于代码和计算任务执行的云计算抽象模型,与之相对的是基于服务器(虚拟机、容器)的计算模式。无服务在公有云和私有云上都有相应的服务,如AWS Lambda、阿里云的函数计算、Kubernetes的Kubeless、Apache OpenWhisk等。无服务聚焦在函数计算,隐藏了底层复杂的实现方式,使开发者能够聚焦于业务本身。可以说微服务的设计、无服务的功能是云原生理念的核心体现,而容器、编排、服务网格均是实现云原生的支撑技术。

◆ 云原生安全包含两层含义:面向云原生环境的安全和具有云原生特征的安全。

◆ 面向云原生环境的安全的目标是防护云原生环境中基础设施、编排系统和微服务等系统的安全。

◆ 这类安全机制不一定具备云原生的特性,比如不是容器化、可编排的,而是以传统模式部署的,甚至是硬件设备,但其作用是保护日益普及的云原生环境。

◆ 因而,虽然我们将云原生安全分成了两种安全机制,但这两种机制会互相融合。在理想情况下,云原生安全会是在云原生环境下,对原有的安全机制进行重构或设计新的安全功能,使得最终的安全机制能与云原生系统无缝融合,最终体现出云原生的安全能力。

连接SSH服务器,使用私钥连接,将比使用密码连接更加安全。

1. 服务器生成密钥对

首先,进入用户家目录:

cd

使用ssh-keygen生成公私钥对:

ssh-keygen -t rsa

过程中可以选择设置密码passphrase或者不设置。

生成后,将在用户家目录下创建.ssh目录,其中包含生成的公私钥对。

其中id_rsa为私钥,id_rsa.pub为公钥。

2. SSH服务器配置

id_rsa.pub名称的公钥的内容导入到~/.ssh/authorized_keys文件中。

cat id_rsa.pub >> ~/.ssh/authorized_keys

3. SSH客户端配置-Windows XShell

id_rsa名称的私钥下载到本地或者复制其内容出来使用,后续将使用该私钥连接到远程服务器。

连接SSH服务器时,选择Public Key(U)方式进行认证,然后将下载的id_rsa文件导入到用户密钥管理器中。

选择『记住密码』,则在后续连接时可以自动连接了。

4. SSH客户端配置-Mac OS终端设置

id_rsa名称的私钥内容拷贝到Mac OS的终端的如下本地私钥文件中,如私钥文件名为private_key_centos_61

本地目录为/Users/harid/.ssh

使用如下命令连接SSH服务器:

ssh root@192.168.3.61 -p 22 -i ~/.ssh/private_key_centos_61

其中-i参数指定本地的私钥文件。

可以将上述命令以别名方式设置到~/.zprofile文件中,以避免每次都需要输入这么长的命令。

5. SSH客户端配置-手机端ConnectBot设置

将下载的id_rsa名称的私钥文件导入到ConnectBot软件中。

导入后,即可编辑连接,设置使用密钥验证

6. 关闭密码认证方式

至此,可以使用私钥进行SSH认证,即可关闭密码认证方式了。

在服务器上,修改/etc/ssh/sshd_config文件内容:

vi /etc/ssh/sshd_config

设置参考如下:

PubkeyAuthentication yes
PasswordAuthentication no

设置完后,重启ssh服务。

service sshd restart

再使用密码登录,将出现:

1. 典型算法业界要求参考

算法 NIST BSI ANSSI
3DES 新系统禁止,2023年底前遗留使用 新系统禁止,2022年底前遗留使用 2020年后不建议使用
HMAC-SHA1 允许 允许,每年例行审视 允许
RSA|DH|DSA(2048bit) 2030年年底前允许 2022年年底前允许2000bit 2030年年底前允许
ECDH|ECDSA|ECIES(224bit) 2030年年底前允许 2022年年底前允许200bit 2020年年底允许200bit

2. NIST官方文档说明

https://csrc.nist.gov/CSRC/media/Publications/sp/800-131a/rev-2/draft/documents/sp800-131Ar2-draft.pdf

3. 其它参考

3.1. https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-retired

3.1.1. Why 3DES is Likely to Be Disallowed after 2023

3DES is a ciphersuite based on the Data Encryption Standard developed by IBM in the early 1970s and adopted by NIST (with minor changes) in 1977. 3DES was introduced during a period of transition between two major algorithms. In 1997, NIST announced a formal search for candidate algorithms to replace DES. In 2001, AES was released with the intention of coexisting with 3DES until 2030, permitting a gradual transition. However, the retirement of 3DES has been likely accelerated by research which has revealed significant vulnerabilities and is, by some accounts, long overdue.

NIST first initiated discussion of deprecating 3DES following the analysis and demonstration of attacks on 3DES. The Sweet32 vulnerability was made public by researchers Karthikeyan Bhargavan and Gaëtan Leurent. This research exploited a known vulnerability to collision attacks in 3DES and other 64-bit block cipher suites which are greatest during lengthy transmissions, the exchange of content files, or transmissions vulnerable to text injection. After the exposure of this vulnerability, NIST proposed 3DES be deprecated, and soon thereafter, restricted its usage.

3.2. https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA

3.3. https://www.encryptionconsulting.com/why-3des-or-triple-des-is-officially-being-retired

1. System Trustworthiness Protection

  • File Integrity Protection
  • Secure Boot

2. Authentication / Authorization Control

  • Identity Authentication
  • Permission Control
  • Account Management

3. Secure Management

  • Log Audit
  • Security Upgrade
  • Security Event Management

4. Security Detection Response

  • Attack Detection
  • Intrution Protection
  • Anti-DoS/DDoS

5. Data Protection

  • Keys Management
  • Data Transmission Security
  • Data Storage Security
  • Personal Data Classification

6. Security Isolation

  • Network Isolation
  • Applications Isolation
  • Comtainer Isolation
  • Sandbox Isolation

7. Privacy Protection

  • Privacy Control
  • Privacy Compliance
  • Data Desensitization

8. Security Deployment

  • Security Hardening
  • Network Scheme Security
  • Secure Compilation