这是一个创建于 2032 天前的主题，其中的信息可能已经有所发展或是发生改变。
阿里云对象存储 OSS 支持在服务器端对上传到存储空间（ Bucket ）的数据进行加密（ Server-Side Encryption ），对持久化在 OSS 上的数据进行加密保护。
上传数据时，OSS 对收到的用户数据进行加密，然后再将得到的加密数据持久化保存下来；下载数据时，OSS 自动对保存的加密数据进行解密并把原始数据返回给用户，并在返回的 HTTP 请求 Header 中，声明该数据进行了服务器端加密。
相关文档： https://help.aliyun.com/document_detail/108880.html
阿里云 oss 增加这个加密功能，是否说明，不加密存放在 oss 上的数据可能被未授权用户访问（被窃取数据）？
 | 1 eatlatency 2020 年 6 月 23 日  1 一个可能的场景是，OSS 存储的一台服务器被物理窃取了，如果开启服务端加密可以保证数据仍然不泄漏(存储密钥的服务器可以投入更多成本进行更高规格的保护）。 虽然这种场景出现的概率很小，如果用户对于安全等级的要求很高的话，仍然会使用这个功能。 |
 | 2 wangyzj 2020 年 6 月 23 日 1 想想为什么很多人不用云上贵州 |
 | 3 Exdui 2020 年 6 月 23 日 大部分人会不经意泄漏阿里云的密钥，该功能可以起到保护数据安全 阿里云的密钥不单单用于 oss，密钥在 github 泄漏案例也不少见了 数据可能被未授权用户访问，这一点是不存在的（拼多多一部分商家数据就是存储在阿里云 oss ） |
 | 4 shabbyin 2020 年 6 月 23 日 加密的数据我记得是需要获取临时的凭证再取请求文件 公共读的文件知道地址就可以访问了 除了企业里可能用到 私人用到私有读、写功能的可能性不大吧 |
 | 5 akira 2020 年 6 月 23 日 有些业务会要求数据落盘的时候 是加密存储的 |
 | 6 opengps 2020 年 6 月 23 日 via Android 我做上云业务，给大家解惑下，瞧得起我的可以顺便过来谈谈业务。 象存储即使是设置有私有读写，文件上传后一段时间内也是可以读出的，源文件加密对于保密文件泄露灾难是个非常好的措施。这样及时丢了也是密文，不会破解拿到手里一点作用没有。 |
 | 7 billlee 2020 年 6 月 23 日 主要是一些行业的合规要求吧？ |
 | 8 realpg PRO 13 搞私有云的，这个比较熟悉。上面大多数人说的都没理解这个是啥。 这些都是防止理论泄露数据可能的一部分，以常见 OSS 系统为例，这个加密的存在，只是让数据安全的风险从 99.999%提升到 99.999999%这么个过程，即使没有，原先的系统也足够安全，同时也是满足一些合规、等保的加密存储要求。 现在 OSS 的系统都是分布式存储，你上传了一个文件，首先控制引擎会把这个文件打散（文件大）或者与其他用户文件组合（文件小）成一个最小单元，然后分配给三个实际存储服务器（假设三副本模式）。 举个实际的例子吧，可能比较极端，也不考虑文件系统占用空间什么的这些，方便理解。 你创建了一个二进制文件，有 4Bytes 0x33 0x44 0x55 0x66 你上传到阿里云，在没有这个加密的时候，首先阿里云的 OSS 控制器，会把这四个 byte 与其他用户的数据组合在一起，凑够一个块大小并记录下你的数据在块的哪个位置，然后去阿里云的比如 1000 个实际存储服务器中，按既定规则根据负载，选出三个，假设是 147,304,828，把这个数据的三份分别存储到这三个服务器硬盘的一个位置，控制器会在自己的存储中记录下这三个位置，等你再需要的时候，去这三个位置的提取出这个块，再从块里的之前记录的位置还原出你的数据 0x33 0x44 0x55 0x66 这个模式下，一个小偷单纯的搬走了比如服务器 828，或者小偷就是 828 服务器的运维有 root 权限，基本都能直接访问裸硬盘设备，那么你的数据 0x33 0x44 0x55 0x66 就面临泄露，但是这在一定程度上仍然是安全的，因为 828 服务器里插了 120TB 的硬盘，鬼知道上哪里找你的 0x33 0x44 0x55 0x66…… 4bytes/120Tbytes 的大海捞针…… 这时候，这个小偷，还得想办法搞到，OSS 控制服务器的存储，这样就会有一个索引，告诉他你那四个字节的重要数据，存在什么位置，这就跨系统了，一般来说，分布式架构下，你搬走了一台存储节点是比较容易的，同时还能搬走控制器数据是比较难的，而且运维也不太容易有全部权限。所以这个机制就造成了比较难泄露。毕竟控制器的存储索引，可能是一些复杂数据结构或者数据库服务，直接盗取相对困难，还得理清逻辑关系。 而本文提到的那个技术呢，就是在控制器确定把 0x33 0x44 0x55 0x66 放在哪之前，在前面的流程上，再加一个加解密服务，把 0x33 0x44 0x55 0x66 变成了可能是 0x77 0x88 0x99 0xaa，这样就算比较难得完成了刚才说的那两个部分全部掌握，获取到的也是密文。中间这个加解密服务，必然是依据密钥管理的机制，存储、操作的内容均跟运维脱钩的方式管理，更难获取。 |
 | 9 lihongming 2020 年 6 月 24 日 via iPhone 根据我考 AWS 认证的经验来看，涉及 S3 服务端加密的题目一般都是“根据 XXX 的要求”，所以 7 楼说的对，这更多是为了合规，其实泄密风险极低，一般人无需考虑这个。 |
 | 10 ericls 2020 年 6 月 24 日 soc2 |
 | 11 mlboy 2020 年 6 月 24 日 via iPhone 防止服务器小哥哥看你的数据 |
 | 13 xfabs 2020 年 6 月 24 日 via iPhone @gyjames95 你说的功能最近刚好在用，这是授权访问，私有读私有写的文件桶就得这样访问文件。加密是另外一个功能，6 楼正解。 |
 | 15 AngryPanda 2020 年 6 月 24 日 via Android @realpg 这个模式下，一个小偷单纯的搬走了比如服务器 828，或者小偷就是 828 服务器的运维有 root 权限，基本都能直接访问裸硬盘设备，那么你的数据 0x33 0x44 0x55 0x66 就面临泄露 -------------- 这里没看明白，因为数据是分布式存储，小偷拿走了 828，那么面临泄露的数据，应该是 828 上存储的数据片段，而不是 0x33 -0x66 全部吧？谢谢解答 |
 | 16 red2dog 2020 年 6 月 24 日 加密必须设置过期时间，可以防止敏感照片泄露，如银行卡身份证。 |
 | 17 cigarzh 2020 年 6 月 24 日 主要是能过一些认证和等保要求，比如 ISO/IEC 27040 里面就规定了你就得这么搞 |
| 18 realpg PRO |
| 19 realpg PRO @watzds #14 整个硬盘都是一个连续数据段 问题是你不知道那个数据是啥 扔给你是没用的 要么你知道怎么存的 要么你知道原始数据是啥 硬盘数据恢复这种盲恢复都是建立在文件系统已知或者可在小范围内遍历，然后可以依赖文件存储模式进行匹配 而一个未知的裸盘数据直存文件系统 很多还是为机械硬盘优化的存储模式 你不了解其实现的情况下 是很难的 |
| 20 AngryPanda 2020 年 6 月 24 日 @realpg 没有多副本，那如何保证数据的安全呢？ |
| 21 AngryPanda 2020 年 6 月 24 日 @realpg 抱歉理解错误，可能是多副本都一样的内容 |
| 22 AngryPanda 2020 年 6 月 24 日 没事了，脑子短路。。。。。 |
 | 24 chinvo 2020 年 6 月 24 日 via iPhone @Exdui #19 用 access key 和 secret key，上传时自动加密，下载时自动解密，何谈“下载的文件是加密的” |
 | 25 iyaozhen 2020 年 6 月 24 日 我们做个自己加解密 做一层代理 |
 | 27 fanyuxi 2020 年 6 月 24 日 更多的是合规和宣传的意义吧 |
 | 28 vincent321 2020 年 6 月 24 日 一般是为了满足合规的要求 |
Select Language