
1.功能介绍 利用阿里云的快照能力,您可以针对单个云盘(包括系统盘和数据盘)创建指定时间点的快照。阿里云将该快照存放在对应Region的OSS中。在快照创建完成并成功存放到OSS后,您可以将指定的快照从一个Region复制到另一个Region,您也可在相同Region内复制快照。复制后的快照副本将拥有与源快照不同的ID。 2. 使用场景 DevOps:需要在新的区域快速启用业务;或者将业务系统迁移到新的区域,以最大限度降低成本以及实现更好的可用性 跨地域备份:基于“合规审计”或者“提高业务可靠性”要求,在发生灾难时,能够在辅助Region恢复业务系统,将RTO和RPO降至最低 3.使用限制 1.将快照复制到新的区域,将创建1个完整(非增量)的快照副本。因此,除了会产生“跨区域复制的流量费用”外,还会在新区域产生快照存储费用。 2.复制的新快照不能回滚源快照对应的云盘 3.不支持同时复制源快照绑定的标签 #4.支持的区域1.部分地域支持复制快照: 这些地域之间支持互相复制快照:华东1(杭州)、华东2(上海)、华北1(青岛)、华北2(北京)、华北3(张家口)、华北5(呼和浩特)、华北6(乌兰察布)、华南1(深圳)、华南2(河源)和西南1(成都)。 这些地域之间支持互相复制快照:美国(硅谷)和美国(弗吉尼亚)。 5.计费&定价 快照复制到新的地域时,将创建一个快照副本。快照复制费用包括不同地域复制过程中产生的快照复制服务费用和快照副本产生的快照存储费用。更多详情,请参见快照计费。 说明 一块云盘的快照第一次被复制时,复制的是完整容量,后续在相同地域复制该云盘的新快照时,采用增量复制。快照计费的计量项为容量,增量复制能显著降低存储容量。 5.通过自动快照策略定期跨地域复制 1.登录ECS管理控制台。2.在左侧导航栏,单击存储与快照 > 快照。3.在顶部菜单栏左上角处,选择地域。4.在快照列表页中,选择自动快照策略。5.在自动快照策略页面,单击右上角创建策略。 6.手工复制快照 1.登录ECS管理控制台。2.在左侧导航栏,单击存储与快照 > 快照。3.在顶部菜单栏左上角处,选择地域。4.找到目标快照,在操作列中,单击复制快照。 5.在弹出复制快照对话框中,配置参数。 7.新增API 1.API接口:CopySnapshot
产品介绍: 数据库文件存储(DBFS)是一款针对数据库场景、基于共享存储架构设计的云原生共享文件存储系统,它基于共享存储架构设计,通过文件协议提供数据库定制功能,具备企业级存储特性。主要服务于云上自建数据库,基于传统SAN的应用等,为用户提供极致IO性能和高可用性。同时减少数据库直接基于块的架构复杂度和成本(例如数据库做主备容灾的场景等),提供IO加速、多点读写的多活、数据备份及保护等能力适用客户: 适用于自建数据库场景发布功能: DBFS相比以下方案的优势:高效云盘/SSD+ext4:成本不变,性能提升40%+ESSD云盘+ext4:性能提升20%+;共享下成本至少下降50%本盘I型+ext4:性能满足,高可用增加;共享下成本下降50付费方式: 目前仅支持包年包月模式产品文档: https://help.aliyun.com/product/140631.html?spm=5176.cndbfs.0.0.494dd15c47jtmE
Part1:产品规格介绍 基于全闪存储介质的ESSD PL0新规格正式在杭州以及北京区域上线公测。ESSD PL0作为ESSD系列入门级规格,采用与ESSD系列相同的技术架构,同样拥有亚毫秒级别的延时,单卷最大支持10000的IOPS。 此次全新发布的ESSD PL0 采用NVMe存储介质,最大程度上释放阿里云的技术红利。这也是业内唯一一款基于“RDMA网络架构+NVMe存储介质”的入门级云盘。 Part2:应用场景 ESSD PL0作为入门级规格,适用于多种业务场景。例如:小型数据库场景、DevOps场景、系统盘场景。线上实测“搭载ESSD PL0的六代增强型实例”启动速度提升了60%以上;此外针对DevOps场景,基于ESSD系列云盘的“本地快照”特性,能够在数十秒内快速完成快照创建以及云盘创建操作,将业务等待时间缩短至分钟级别;针对小型数据库场景,基于ESSD PL0云盘搭建的数据库实测TPS性能相比于高效云盘提升2倍以上。 Part3:丰富的企业级特性 相比于高效云盘、SSD云盘,ESSD系列云盘拥有更丰富的企业级特性。例如,本地快照、块跨区域复制等特性。基本上可以满足中高端客户对于安全合规的诉求。 目前ESSD PL0 已经在北京i和杭州h区域公测上线,欢迎各位购买使用~
1.云盘加密介绍 当前阿里云云盘提供KMS加密方案,您除了可以使用默认服务密钥外,还可以使用事先在KMS服务中创建好的CMK进行加密。整个云盘加密过程都是在ECS端完成,可确保静态数据安全以及ECS实例与后端块存储集群之间传输数据的安全性。 2.加密原理 云盘加密采用AES256机制,授权的用户在控制台选择指定CMK ID时,ECS服务通过角色扮演方式,向KMS请求一对明文密钥以及密文密钥,ECS服务在获取密钥对后,将密文密钥保存至云盘meta信息中。此后,每次挂载云盘或者重启ECS实例时,ECS服务向kms服务获取明文密钥,并将该密钥用于每个I/O加密操作。当前阿里云云盘服务仅支持AES256加密机制。后续我们也会逐步演进并支持更多国密算法。 3.使用限制 • 当前所有的云盘类型均支持加密• 目前不直接支持系统盘加密,如果要针对系统盘加密,则需要通过镜像加密方式完成• 加密会影响云盘的IO性能,IO密集型场景请根据实际情况评估是否开启云盘加密功能• 针对加密云盘创建的快照,默认也是加密状态,并且使用与云盘相同的加密密钥 4.控制台操作 云盘服务默认会在每个region创建1个阿里云托管的KM密钥(Default Service CMK),您可以使用该默认托管的密钥进行加密,也可以选择事先在KMS服务中创建的CMK ID。我们建议您使用指定的CMK 进行加密,这样更加灵活以及便于管理(包括密钥轮转,密钥激活等)如下图所示,授权的 用户在创建云盘时,可以选择指定的CMK 进行加密。
一、快照服务介绍 1.1本地快照介绍 阿里云为您提供快照功能,您可以通过管理控制台或者API接口创建云盘本地快照。云盘本地快照指的是云硬盘数据在某个时刻的完整拷贝或镜像,本地快照数据与云盘数据存储在一起,可以支持快速备份和恢复,是一种重要的数据容灾手段,当数据丢失时,可通过快照将数据完整的恢复到快照时间点。 1.2普通快照介绍 阿里云普通快照提供对云盘基于快照技术的数据保护机制。云盘系统自动将指定时间点的数据传输至OSS。普通快照属于增量快照,这意味着除第一次是完整快照外,后续新创建的快照只保留变化的数据块。 1.3本地快照与普通快照区别 普通快照以及本地快照为存储在云盘中的数据提供冗余备份,确保高可靠性。其主要区别如下: 指标 存储方案 数据同步 适用范围 容灾范围 业务恢复 普通快照 与云盘数据分开存储,存储在对象存储(OSS)中 保存云盘指定时刻的数据 ALL云盘类型 与云盘位于同一个区域内,可以是不同AZ 通过恢复普通快照至云盘,或者通过快照创建新的云盘,找回数据,恢复业务。 本地快照 与云盘数据存储在一起.说明:普通快照由于数据搬迁会耗费一定的时间,创建本地快照和回滚快照数据的速度比普通快照快。 保存云盘指定时刻的数据 有限类型 与云盘位于同一个AZ内 通过回滚快照至云盘,或者通过快照创建新的云盘,找回数据,恢复业务。 1.4本地快照使用场景: 本地快照主要使用场景如下: • 关键业务系统快速进行备份;。例如RDS以及容器产品快速备份、SAP • 高危操作前进行备份。例如云盘扩容、更新补丁 • DevOps场景:原有ECS实例,需要快速在其他Region或者同region启动相同配置的实例 二、控制台创建本地快照 2.1针对云盘创建快照 针对云盘创建快照时,可以让用户选择是否创建“本地快照”or“普通快照”。特别说明:只有针对ESSD类型云盘创建快照时,在切换到如下界面。针对其他类型云盘创建快照时,界面不变(默认还都是普通快照)。 说明:• 1个ESSD云盘最多只能创建10个本地快照,当快照数量超过10个后,继续创建快照时,提示错误; 2.2查看快照列表 “快照列表”页面插入“快照类型”。以区别当前的普通快照以及本地快照; 2.4快照链列表 针对本地快照,提供1种新的快照链类型,如下图所示。以区分“本地快照”和“普通快照”: 2.5快照容量 可以在快照容量页面,直观的看到,当前Region内,本地快照和普通快照的容量信息。如下图所示: 三、FAQ 本地快照支持的云盘类型:ESSD 单个云盘支持的最大本地快照数量:10个 创建本地快照方式:手工、自动快照策略(暂不支持) 当前还处于公测阶段。如需测试,可通过工单申请
1.背景 云计算已经成为行业发展趋势,越来越多的企业将生产系统、数据库等关键业务迁移到云上。由于基础架构发生变化,传统的备份软件/备份一体机方式并不适合云上ECS以及RDS等数据备份以及容灾场景。面对ECS云盘物理故障或者逻辑故障(例如,云盘感染病毒、数据误删除、配置错误等),阿里云提供云原生数据保护服务--快照。用户可针对关键生产系统创建手工快照或者自动快照,确保业务系统发生灾难时,也可快照进行数据恢复。 2.快照技术原理介绍 阿里云快照服务采用ROW(Redirect On Write)模式。用户在首次创建快照时,复制一份完整的备份数据,此后所有的快照均采用“永久增量”模式。并将快照数据异步存储到同Region的OSS集群上。 【创建快照】: 快照服务采用多线程机制,将云盘中变化的数据块(快照不备份空数据块),异步复制到同Region的OSS集群中。备份速度达到达到30MB/S-40MB/S。此外,快照采用永久增量方式,每次仅保存变化的数据块。但是每个快照时间点都是完整的备份数据 【恢复快照】: 在进行快照回滚或者基于快照创建云盘时,快照服务默认采用Lazyload方式,秒级回滚云盘,即刻可用。并不需要等待快照将所有的数据全部复制到云盘上 3.快照使用场景介绍 作为一种高效、便捷的数据保护方式,我们推荐您在如下3种场景下使用“快照服务”: 3.1备份容灾场景--基于快照回滚云盘 高危操作前创建快照: 在更换操作系统、应用软件升级或业务数据迁移等重大操作前,建议您创建一份或多份快照。一旦升级或者迁移过程中出现任何问题,可以通过快照及时恢复到正常的系统数据状态 关键业务系统定期创建快照,应对病毒、误操作、外部攻击等风险: 利用快照定期备份磁盘上重要的业务数据,应对误操作、攻击和病毒等导致的数据丢失风险 当升级版本后出现系统问题时,您能使用快照回滚云盘实现版本回退 当团队成员不慎在磁盘上存储了错误的数据、ECS实例误被释放、应用错误导致了数据错误或者骇客利用应用漏洞恶意读写数据时,您可以使用快照将磁盘上的数据恢复到期望状态 3.2备份容灾场景--基于快照跨可用区创建云盘 云盘同城容灾: 为某块磁盘创建快照,将数据作为其他磁盘的基础数据。实现同城容灾 3.3DevOps场景--基于快照快速构建测试环境 数据开发: 通过对生产数据创建快照,从而为数据挖掘、报表查询和开发测试等应用提供近实时的真实生产数据 4.快照开通方式介绍 快照服务支持多种开通方式,您可以在购买ECS或者云盘时一键启用“自动快照策略”。针对已经存在的云盘也可以手工创建快照或者将现有快照策略附加到指定的云盘。 4.1方式一:购买ECS时启用自动快照策略 用户可以在创建ECS实例时,为系统盘或者数据盘启用自动快照策略: 登录ECS管理控制台 在左侧导航栏,选择实例与镜像 > 实例 在页面右上角,单击创建实例。创建一台ECS实例的详细步骤请参见使用向导创建实例 需要在基础配置的存储选项处,为系统盘或者数据盘勾选启用自动快照策略,并选择其中一条自动快照策略。若该Region不存在自动快照策略,则快照服务会默认创建1条Default Policy 4.2方式二:购买云盘时启用自动快照策略 用户可以在购买云盘时,启用自动快照策略: 登录ECS管理控制台 在左侧导航栏,选择存储与快照 > 云盘 在页面右上角,单击创建云盘。创建一块云盘的详细步骤请参见创建按量付费云盘或创建预付费云盘 勾选“启用自动快照策略”,并选择一条自动快照策略 批量创建云盘时,若启用了自动快照策略,那么批量创建的云盘也会收到自动快照策略保护 4.3方式三:在云盘页面创建手工快照或者执行自动快照策略 可以在ECS控制台的云盘页面,为系统盘或者数据盘执行或取消自动快照策略。 登录ECS管理控制台 在左侧导航栏,选择存储与快照 > 云盘 在顶部状态栏处,选择地域 找到要设置的云盘,在操作列,选择设置自动快照策略 在设置自动快照策略对话框中,开启或关闭自动快照策略的开关 4.4方式四:在快照页面执行自动快照策略 可以在ECS控制台的快照页面,为系统盘或者数据盘执行或取消自动快照策略。 登录ECS管理控制台 在左侧导航栏,选择存储与快照 > 快照 在顶部状态栏处,选择地域 在快照列表页中,选择自动快照策略 在自动快照策略页面,找到需要修改的策略,在操作列,单击设置磁盘 在设置磁盘页面,单击未设置策略磁盘页签,找到要执行策略的磁盘,单击其右侧的执行快照策略或者选择多个磁盘,单击下面的执行快照策略 单击设置自动快照策略页面右上角的关闭图标,退出设置 5.快照价格FAQ 1.快照价格介绍?答:快照目前有2种计费模式,一种是“按量付费”,大陆地区每GB快照数据每月0.12元,详细价格信息参见:快照定价。另一种是“包年包月”,可以使用OSS资源包进行抵扣; 2.快照容量统计方式?答:阿里云快照服务按照“首次全量快照”+“永久增量快照”方式进行统计快照容量。首次全量快照仅针对实际存储在云盘中的数据进行计费。例如用户创建了500GB的云盘,但是该云盘实际只存放了40GB的数据,那么首次创建快照时,快照服务仅针对40GB实际存储空间进行计费;“永久增量快照”是指仅针对变化的快照数据进行收费,例如,用户创建了500GB的云盘,实际只存储了40GB的数据,第二次创建快照前,该云盘“新增+修改”了10GB的数据,那么第二次创建快照时,仅需针对变化的10GB数据进行计费;
1.背景 阿里云快照服务提供手工以及自动快照策略,用户可根据实际数据保护需求针对不同的ECS以及云盘运用不同的快照策略。该方式比较灵活,定制化能力强,适合不同的数据保存场景。 但是自动快照策略需要事先创建好策略,然后在附加到指定的云盘。部分用户创建完策略后经常漏勾选指定的云盘,导致没有按时创建快照。因此,阿里云快照服务推出“一键启用自动快照策略”,用户在购买ECS以及云盘时,可以勾选默认快照策略或者选择事先创建好的自动快照策略。 2.创建ECS实例时启用自动快照策略 用户可以在创建ECS实例时,为系统盘或者数据盘启用自动快照策略: 登录ECS管理控制台 在左侧导航栏,选择实例与镜像 > 实例 在页面右上角,单击创建实例。创建一台ECS实例的详细步骤请参见使用向导创建实例 需要在基础配置的存储选项处,为系统盘或者数据盘勾选启用自动快照策略,并选择其中一条自动快照策略。若该Region不存在自动快照策略,则快照服务会默认创建1条Default Policy 3.创建云盘时启用自动快照策略 用户可以在购买云盘时,启用自动快照策略: 登录ECS管理控制台 在左侧导航栏,选择存储与快照 > 云盘 在页面右上角,单击创建云盘。创建一块云盘的详细步骤请参见创建按量付费云盘或创建预付费云盘 勾选“启用自动快照策略”,并选择一条自动快照策略 批量创建云盘时,若启用了自动快照策略,那么批量创建的云盘也会收到自动快照策略保护 快照服务作为阿里云为ECS以及云盘提供的云原生数据保护方式,具有侵入性小、灵活性高、易用性强等特性。强烈建议您为关键业务系统所在的ECS云盘启用自动快照策略。当云盘物理损坏或者云盘数据发生逻辑故障(例如,云盘感染病毒、补丁更新失败导致蓝屏、配置错误等),可以通过快照服务快速回滚至最近时间点。 4.快照价格FAQ 1.快照容量统计方式?阿里云快照服务按照“首次全量快照”+“永久增量快照”方式进行统计快照容量。首次全量快照仅针对实际存储在云盘中的数据进行计费。例如用户创建了500GB的云盘,但是该云盘实际只存放了40GB的数据,那么首次创建快照时,快照服务仅针对40GB实际存储空间进行计费;“永久增量快照”是指仅针对变化的快照数据进行收费,例如,用户创建了500GB的云盘,实际只存储了40GB的数据,第二次创建快照前,该云盘“新增+修改”了10GB的数据,那么第二次创建快照时,仅需针对变化的10GB数据进行计费; 2.快照收费方式?目前快照服务有2种计费方式。一种是“包年包月模式”--使用OSS资源包进行抵扣;另一种是“按量付费模式”。详细快照定价信息可参见:快照定价
1.云盘在线扩容介绍 阿里云支持针对正在使用中(running状态)的云盘进行在线扩容,用户无需重启(reboot instance)实例即可完成物理空间扩容。 2.云盘在线扩容操作演示 您可以通过控制台或者API方式完成在线kuo扩容。如下演示用如何通过控制台完成在线扩容。若您使用API方式,请使用ResizeDisk命令完成。 2.1Step1:准备工作 为了扩容过程中操作失败导致数据丢失,强烈建议您在扩容之前“创建快照” 当前在线扩容支持所有的Region,但仅支持“高效云盘”、“SSD云盘”以及“普通云盘”,暂不支持ESSD云盘 云盘在线扩容仅是扩展云盘物理空间,并不调整分区以及文件系统的大小。因此完成“云盘在线扩容”后,需根据实际情况扩展磁盘分区以及文件系统 MBR格式分区不支持大于2 TiB的云盘容量。如果待扩容的云盘采用的是MBR分区格式,且需要扩容到超过2 TiB时,建议您重新创建并挂载一块数据盘,然后使用GPT分区方式并将数据拷贝至新数据盘中 对于Windows实例,仅支持NTFS文件系统扩容 2.2Step2:线扩容操作 登录ECS控制台 在左侧导航栏,选择存储与快照 > 云盘 为了防止扩容中操作失败,强烈建议您在操作“云盘在线扩容”之前,针对待扩容的云盘创建快照 找到需要扩容的云盘,在操作列表中选择 更多 > 磁盘扩容 勾选“在线扩容”,如下图所示: 设置扩容后的容量(最大支持6144GB),变更后的容量不允许小于当前容量 完成支付 2.3Step:扩容分区&文件系统 详细操作步骤请参考:“在线扩容云盘”
一、背景 目前上云已经成为行业发展趋势,越来越多的企业级客户将业务系统和数据库迁移到云上。而传统的备份一体机/备份软件方式,并不适合云上ECS、RDS等产品的备份与容灾服务。阿里云块存储服务提供云原生的快照服务,通过针对关键业务系统的自动以及手工快照,确保用户业务系统在发生灾难时,也能够快速进行业务恢复。 二、技术原理解析 阿里云快照服务采用ROW(Redirect On Write)模式。用户在首次创建快照时,复制一份完整的备份数据,此后所有的快照均采用“永久增量”模式。并将快照数据异步存储到同Region的OSS集群上。OSS集群与块存储集群物理隔离部署,并且提供11个9的数据可靠性。因此,能够确保快照数据的足够安全。如下阿里云快照服务的逻辑示意图: 在创建快照的时候,快照服务采用多线程机制,将云盘中变化的数据块(快照不备份空数据块),异步复制到同Region的OSS集群中。目前快照的备份速度能够达到35MB/S-40MB/S。 快照采用永久增量方式,每次仅保存变化的数据块。但是每个快照时间点都是完整的备份数据。在进行快照回滚或者基于快照创建云盘时,阿里云默认采用Lazyload方式,秒级回滚云盘,即刻可用。并不需要等待快照将所有的数据全部复制到云盘上。 针对于海量云盘场景,阿里云快照服务提供自动化策略。用户可基于指定时间点(每天、每周)定时创建快照,并指定快照的保存时间,过期快照自动删除。 三、快照数据加密 随着等保2.0的发布,越来越多的行业对数据的安全以及合规性提出了更严格的要求。阿里云快照数据支持BYOK加密方式。针对BYOK加密的云盘创建的快照,默认也是加密状态,并且使用对应的CMK ID进行加密。拥有对应密钥权限的用户才能进行快照数据回滚,基于快照创建镜像等操作。 四、快照容灾场景 作为一种便捷高效的数据保障手段,我们推荐您在以下业务场景中使用快照: 容灾备份:为某块磁盘创建快照,将数据作为其他磁盘的基础数据。实现同城容灾和异地容灾。 版本回退:当升级版本后出现系统问题时,您能使用快照回滚云盘实现版本回退。 环境复制:如果您希望新购实例与已有的实例有完全相同的环境,您能使用系统盘快照创建自定义镜像,再使用自定义镜像创建实例。 数据开发:通过对生产数据创建快照,从而为数据挖掘、报表查询和开发测试等应用提供近实时的真实生产数据。 提高操作容错率: 当团队成员不慎在磁盘上存储了错误的数据、ECS实例误被释放、应用错误导致了数据错误或者骇客利用应用漏洞恶意读写数据时,您可以使用快照将磁盘上的数据恢复到期望状态。 利用快照定期备份磁盘上重要的业务数据,应对误操作、攻击和病毒等导致的数据丢失风险。 在更换操作系统、应用软件升级或业务数据迁移等重大操作前,建议您创建一份或多份快照。一旦升级或者迁移过程中出现任何问题,可以通过快照及时恢复到正常的系统数据状态
一、LVM简介 LVM是逻辑盘卷管理(Logical Volume Manager)的简称,它是Linux环境下对磁盘分区进行管理的一种机制,LVM是建立在硬盘和分区之上的一个逻辑层,来提高磁盘分区管理的灵活性。 LVM最大的特点就是可以对磁盘进行动态管理。因为逻辑卷的大小是可以动态调整的,而且不会丢失现有的数据。如果我们新增加了硬盘,其也不会改变现有上层的逻辑卷。作为一个动态磁盘管理机制,逻辑卷技术大大提高了磁盘管理的灵活性。如果期望扩容云盘的IO能力,则可以通过将多块容量相同的云盘做RAID0。 图1:LVM逻辑示意图(图片来自于互联网) 二、创建LVM卷 2.1步骤一 创建物理卷PV 如下以5块云盘通过LVM创建弹性可扩展逻辑卷为例。 root@lvs06:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 40G 0 disk └─vda1 252:1 0 40G 0 part / vdb 252:16 0 1T 0 disk vdc 252:32 0 1T 0 disk vdd 252:48 0 1T 0 disk vde 252:64 0 1T 0 disk vdf 252:80 0 1T 0 disk step1: 以root账号登录云服务器 step2:执行以下命令,为云盘创建PV卷 pvcreate <磁盘路径1> ... <磁盘路径N> 说明:此处需要填写云盘的设备名称,如果需要添加多个云盘,则可以添加多云盘设备名称,中间以空格间隔。如下以/dev/vdb, /dev/vdc,/dev/vdd,/dev/vde,/dev/vdf为例,执行结果如下: root@lvs06:~# pvcreate /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf Physical volume "/dev/vdb" successfully created. Physical volume "/dev/vdc" successfully created. Physical volume "/dev/vdd" successfully created. Physical volume "/dev/vde" successfully created. Physical volume "/dev/vdf" successfully created. step3:执行以下命令,查看该服务器上物理卷(PV)信息: lvmdiskscan | grep LVM 执行结果如下: root@lvs06:~# lvmdiskscan | grep LVM /dev/vdb [ 1.00 TiB] LVM physical volume /dev/vdc [ 1.00 TiB] LVM physical volume /dev/vdd [ 1.00 TiB] LVM physical volume /dev/vde [ 1.00 TiB] LVM physical volume /dev/vdf [ 1.00 TiB] LVM physical volume 5 LVM physical volume whole disks 0 LVM physical volumes 2.2步骤二 创建卷组(VG) step1:执行以下命令,创建卷组(VG) vgcreate <卷组名> <物理卷路径1>……<物理卷路径N> 执行结果如下: root@lvs06:~# vgcreate lvm_01 /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf Volume group "lvm_01" successfully created 说明: 1.卷组名:该参数可自定义 2.物理卷路径:此处填写云盘的物理卷名称,多个物理卷直接以空格间隔 3.当提示 “Volume group XXX successfully created”标识卷组创建成功; - step2:执行以下命令,可以向卷组(VG)中添加物理卷(PV) vgextend 卷组名称 <物理卷路径1>……<物理卷路径N> 如下,向卷组(VG)lvm_01中添加一块新的物理卷: root@lvs06:~# pvcreate /dev/vdg Physical volume "/dev/vdg" successfully created. root@lvs06:~# vgextend lvm_01 /dev/vdg Volume group "lvm_01" successfully extended step3:创建卷组(VG)成功后,可通过vgs,vgdisplay命令查看卷组信息 root@lvs06:~# vgs VG #PV #LV #SN Attr VSize VFree lvm_01 6 0 0 wz--n- <6.00t <6.00t 2.3步骤三 创建逻辑卷(LV) step1:执行以下命令创建逻辑卷(LV) lvcreate [-L <逻辑卷大小>][ -n <逻辑卷名称>] <卷组名称> 参数说明: 1.逻辑卷大小:逻辑卷的大小应小于卷组(VG)剩余可用空间,单位可以选择MB、GB或者TB 2.逻辑卷名称:可自定义 3.卷组名称:此处填写逻辑卷所在的卷组名称 本文以创建1个4TB的逻辑卷(LV)为例,执行结果如下: root@lvs06:~# lvcreate -L 5T -n lv01 lvm_01 Logical volume "lv01" created. step2:执行lvdisplay命令查看,逻辑卷详细信息: root@lvs06:~# lvdisplay --- Logical volume --- LV Path /dev/lvm_01/lv01 LV Name lv01 VG Name lvm_01 LV UUID svB00x-l6Ke-ES6M-ctsE-9P6d-dVj2-o0h3Kz LV Write Access read/write LV Creation host, time lvs06, 2019-06-06 15:27:19 +0800 LV Status available # open 0 LV Size 5.00 TiB Current LE 1310720 Segments 6 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 2.4步骤四 创建并挂载文件系统 step1:执行以下命令,在创建好的逻辑卷(LV)上创建文件系统 mkfs.文件系统格式 逻辑卷路径 针对上一步中的逻辑卷创建ext4文件系统,执行结果如下: root@lvs06:~# mkfs.ext4 /dev/lvm_01/lv01 mke2fs 1.44.1 (24-Mar-2018) Creating filesystem with 1342177280 4k blocks and 167772160 inodes Filesystem UUID: 2529002f-9209-4b6a-9501-106c1145c77f Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done step2:执行以下命令挂载文件系统: mount 逻辑卷路径 挂载点 执行结果如下: root@lvs06:~# mount /dev/lvm_01/lv01 /media/lv01 root@lvs06:~# df -h Filesystem Size Used Avail Use% Mounted on udev 12G 0 12G 0% /dev tmpfs 2.4G 3.7M 2.4G 1% /run /dev/vda1 40G 3.6G 34G 10% / tmpfs 12G 0 12G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 12G 0 12G 0% /sys/fs/cgroup tmpfs 2.4G 0 2.4G 0% /run/user/0 /dev/mapper/lvm_01-lv01 5.0T 89M 4.8T 1% /media/lv01 三、进阶场景 3.1扩展逻辑卷以及系统容量 Step1:执行以下命令,可扩展逻辑卷的容量 lvextend [-L +/- <增减容量>] <逻辑卷路径> 参数说明: 1.增减容量:当卷组中可剩余容量时 ,可以执行扩容逻辑卷操作。扩容逻辑卷之后还需要扩容对应的文件系统才能生效; 2.逻辑卷路径:此处填写带扩容的逻辑卷路径 如下针对/dev/lvm_01/lv01 卷再扩容500GB物理空间,执行结果如下: root@lvs06:~# lvextend -L +500GB /dev/lvm_01/lv01 Size of logical volume lvm_01/lv01 changed from 5.00 TiB (1310720 extents) to <5.49 TiB (1438720 extents). Logical volume lvm_01/lv01 successfully resized. step2:执行pvs命令,查看物理卷(pv)使用情况: root@lvs06:~# pvs PV VG Fmt Attr PSize PFree /dev/vdb lvm_01 lvm2 a-- <1024.00g 0 /dev/vdc lvm_01 lvm2 a-- <1024.00g 0 /dev/vdd lvm_01 lvm2 a-- <1024.00g 0 /dev/vde lvm_01 lvm2 a-- <1024.00g 0 /dev/vdf lvm_01 lvm2 a-- <1024.00g 0 /dev/vdg lvm_01 lvm2 a-- <1024.00g <523.98g step3:执行以下resize2fs命令扩容文件系统: resize2fs 逻辑卷路径 执行结果如下: root@lvs06:~# resize2fs /dev/lvm_01/lv01 resize2fs 1.44.1 (24-Mar-2018) Filesystem at /dev/lvm_01/lv01 is mounted on /media/lv01; on-line resizing required old_desc_blocks = 640, new_desc_blocks = 703 The filesystem on /dev/lvm_01/lv01 is now 1473249280 (4k) blocks long. step4:执行df-h名称,查看文件系统扩容情况 root@lvs06:~# df -h Filesystem Size Used Avail Use% Mounted on udev 12G 0 12G 0% /dev tmpfs 2.4G 3.7M 2.4G 1% /run /dev/vda1 40G 3.6G 34G 10% / tmpfs 12G 0 12G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 12G 0 12G 0% /sys/fs/cgroup tmpfs 2.4G 0 2.4G 0% /run/user/0 /dev/mapper/lvm_01-lv01 5.5T 83M 5.2T 1% /media/lv01
1.RAID简介 RAID是将多个独立的磁盘按照一定的方式组成1个磁盘阵列组,相比单个磁盘能够有效的提高磁盘的容量、带宽以及可靠性和可用性。 说明: 1.不建议对云盘采用RAID5 和RAID6模式,这些RAID模式的奇偶校验数据会占用一定的IOPS,从而造成性能的损失 2.建议创建RAID0,RAID1模式,并使用相同分区大小,以减少云盘空间的浪费 如下是常见的RAID配置选项: 配置 优点 劣势 使用场景 RAID0 I/O在卷内以条带化的方式分布在各个磁盘上。增加云盘空间会直接增加吞吐量。存储空间等于各个云盘之和 没有数据冗余能力,单个云盘的损坏有可能造成整个虚拟盘数据丢失 对 I/O 性能要求很高,并且已通过其他方式对数据进行备份处理或者不需要进行数据备份的场景 RAID1 数据以镜像的方式存储在各个磁盘上。虚拟盘的存储空间大小取决于RAID组内容量最小的云盘 写性能比较差,因为数据要同时写入多个磁盘 当容错能力比 I/O 性能更重要时;例如在关键应用程序中 相比于单个云盘,通过设置RADI0整列,文件系统可以获得更高的性能。RAID0整列的容量等于各个云盘容量之和,RAID0整列的带宽等于各个云盘带宽之和;为了获取更高的“冗余性”,可以设置RAID1阵列,RAID1提供“镜像”特性,数据同时存放2份副本。RAID1阵列中的容量和带宽等于该RAID1组中容量和带宽最小的云盘。 2.在Linux上创建RAID组 以下配置过程以Ubuntu环境为例。Linux 内核提供用于管理 RAID 设备的 md 模块,可以直接使用 mdadm 工具来调用 md 模块创建 RAID组。 2.1在Linux上创建RAID组 Step1:创建云盘。建议为ECS创建具有相同大小、规格的云盘。更多帮助信息请参阅:创建云盘 Step2:挂载云盘:将Step1中创建好的云盘挂在给指定的ECS服务器。更多帮助信息请参阅:挂载云盘 Step3:使用mdadm命令创建RAID组。可以使用 lsblk 命令列出实例上的设备以找到设备名称。 1.要创建RAI0,请执行如下命令(--level=0 选项用于将阵列条带化) mdadm --create /dev/md0 --level=0 --raid-devices=5 /dev/vd[bcdef] 最终配置信息如下图所示;"/dev/vd[bcdef]"表示/dev/vdb,/dev/vdc,/dev/vdd./dev/vde,/dev/vdf这5个云盘; 2.要创建RAID1,请执行以下命令(--level=1 选项用于将阵列镜像化) mdadm --create /dev/md0 --level=1 --raid-devices=5 /dev/vd[bcdef] Step4:通过如下命令查看RAID信息: mdadm --detail /dev/md0 如下是示例输出信息: root@iZuf698rtvi9j9uskgv84tZ:~# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Sun May 19 12:31:53 2019 Raid Level : raid0 Array Size : 104775680 (99.92 GiB 107.29 GB) Raid Devices : 5 Total Devices : 5 Persistence : Superblock is persistent Update Time : Sun May 19 12:31:53 2019 State : clean Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Name : iZuf698rtvi9j9uskgv84tZ:0 (local to host iZuf698rtvi9j9uskgv84tZ) UUID : 59b65ca6:ad8ffc30:ee439c6b:db6baef1 Events : 0 Number Major Minor RaidDevice State 0 253 16 0 active sync /dev/vdb 1 253 32 1 active sync /dev/vdc 2 253 48 2 active sync /dev/vdd 3 253 64 3 active sync /dev/vde 4 253 80 4 active sync /dev/vdf Step5:创建文件系统:在新建的RAID阵列上创建wenji文件系统,如下以EXT4为例: mkfs.ext4 /dev/md0 输出信息如下: root@iZuf698rtvi9j9uskgv84tZ:~# mkfs.ext4 /dev/md0 mke2fs 1.42.13 (17-May-2015) Creating filesystem with 26193920 4k blocks and 6553600 inodes Filesystem UUID: 4fc55c24-d780-40d5-a077-03b484519e83 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done Step6:创建RAID配置信息:要确保 RAID 阵列在启动时自动重组,需要创建一个包含 RAID 信息的配置文件: sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf Step7:创建挂载点 mkdir /media/raid0 Step8:挂载文件系统,并查看挂载信息: mount /dev/md0 /media/raid0 输出信息如下: root@iZuf698rtvi9j9uskgv84tZ:~# mount /dev/md0 /media/raid0 root@iZuf698rtvi9j9uskgv84tZ:~# df -h Filesystem Size Used Avail Use% Mounted on udev 7.9G 0 7.9G 0% /dev tmpfs 1.6G 3.5M 1.6G 1% /run /dev/vda1 40G 23G 15G 61% / tmpfs 7.9G 0 7.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup tmpfs 1.6G 0 1.6G 0% /run/user/0 /dev/md0 99G 60M 94G 1% /media/raid0 至此,RAID设备已经准备完毕,并且可用。 Step9(可选):若要在每次系统启动时,自动加载该RAID组,则需要在/etc/fstab中添加如下信息: /dev/md0 /media/rad0 defaults,nofail,nobootwait 0 2 说明:如果要在未挂载该RAID组的情况下启动实例,zexuyao添加nofailzhuazhuangzai装载项,该装载项允许ECS实例即使在磁盘安装过程中出现错误时也可启动。对于ubuntu类型还必须添加 nobootwait 装载选项。 Step10(可选):装载文件系统:在将新RAID添加到 /etc/fstab 后,需要检查启动项是否有效。运行 mount -a 命令以在 /etc/fstab 中装载所有文件系统。 mount -a 3.创建RAID整列中云盘的快照 若要为RAID组创建一致的快照,请先停止应用程序对该RAID的写入操作,并将缓存中数据刷新至云盘。停止所有 I/O 活动后,就可以创建快照了。当快照已启动或快照 API 成功返回时,所有 I/O 活动都将安全恢复。从RAID快照中恢复数据时,请先停止所有I/O操作,再将快照恢复至云盘。
1.场景简介 若整块磁盘作为1个分区使用(即不存在多个逻辑分区,例如/dev/vda1,/dev/vda2)。请不要在ECS磁盘上创建分区,而是直接在裸设备上创建文件系统。 2.在裸设备上创建文件系统(如下以ubuntu系统举例) 1.以root身份登录Linux系统 运行如下命令,查看磁盘名称: fdisk -l 回显信息如下图所示,表示当前ECS服务器有两块云硬盘,/dev/vda是系统盘,而/dev/vdb是新添加的数据盘。 3.针对新添加的"/dev/sdb"数据盘,创建文件系统(如下以ext4文件系统举例) mkfs.ext4 /dev/sdb 4.创建挂载点(以 /media/vdb举例) mkdir /media/sdb 5.将新创建的分区挂载至挂载点("/media/vdb") mount /dev/vdb /media/vdb 6.执行以下命令查看挂载情况: df -h 如下图所示,新创建的分区已经挂载成功
一、简介 数据保护是指数据传输(上传数据至OSS、从OSS下载数据)和处于静止状态(数据存储在OSS数据中心磁盘)期间保护数据。可以使用SSL或者客户端加密保护传输中的数据。也可以采用以下方式保护静态数据: 使用服务器端加密 (SSE) --OSS将数据保存到数据中心的磁盘之前进行加密,并且在下载对象时自动进行解密; 使用客户端加密(CSE) --可以使用客户端加密SDK,在本地进行数据加密,并将加密后的数据上传到OSS。在这种场景下,用户需要管理加密过程以及加密密钥。 二、使用服务器端(SSE)加密保护数据 使用服务器端加密方式保护静态数据,即OSS将用户数据写入数据中心内的磁盘时,会在对象级别加密数据,并且在访问这些数据时自动解密。用户只需要验证请求是否拥有访问权限。当前OSS支持如下两种服务端加密方式(注意:不能对同一对象同时应用两种不同类型的服务器端加密方式): 使用由OSS完全托管的服务端加密功能(SSE-OSS):数据加密密钥的生成和管理,由OSS负责,并采用高强度、多因素的安全措施进行保护。数据加密的算法采用使用行业标准的强加密算法AES-256(即256位高级加密标准)。 使用由KMS托管密钥的服务端加密功能(SSE-KMS):除了采用AES-256加密算法外,KMS负责保管用户主密钥CMK(对数据密钥进行加密的密钥),以及生成数据加密的密钥,通过信封加密机制,进一步防止未经授权的数据访问。其中,会涉及少量额外的KMS密钥API调用费用(参考:KMS计费标准)。 2.1使用由KMS托管密钥的服务器端加密(SSE-KMS) 阿里云KMS(Key Management Service)是一项安全、高度可靠的密钥管理系统。当用户上传Object时,在请求中携带x-oss-server-side-encryption 的HTTP Header,并指定其值为KMS,KMS将使用系统默认创建的CMK加密该对象,若用户在请求中指定了X-OSS-server-side-encrpytion-key-id, 那么OSS将使用指定的CMK进行加解密。使用用户自主指定的CMK能够提供更大的灵活性,包括创建、轮转、禁用和自定义访问控制,以及审核用于保护数据的加密密钥能力。 如上是SSE-KMS服务端加密的逻辑示意图。关于Customer Master Key的生成方式有多种,如下一一介绍: 使用OSS默认托管的KMS密钥:当用户上传object时,在请求中携带X-OSS-server-side-encrpytion并指定其值为KMS。OSS将使用默认托管的CMK加密每个对象,并且在下载时自定解密; 使用用户指定的CMK :当用户上传object时,在请求中指定X-oss-server-side-encrpytion-key-id为具体的CMK ID。OSS将使用指定的CMK(密钥材料来源于阿里云KMS)来加密每个对象。并且加密object的CMK ID记录到对象的元数据中,因此具有解密权限的用户下载对象时自动进行解密。 使用用户BYOK材料进行加密:目前阿里云KMS服务支持导入用户自己的BYOK密钥材料。如下图所示,用户创建1个不带密钥材料的CMK,并按照提示导入外部密钥材料。当用户上传object时,在请求中指定X-oss-server-side-encrpytion-key-id为使用外部密钥材料的CMK ID。 注意: • 当首次向某区域中的bucket上传对象时,系统自动为您创建1个默认的CMK。用户可以在KMS控制台查看该密钥信息; • 可以选择自行创建和管理的加密密钥(CMK),也可以选择使用由OSS服务按照Region级别为客户生成的默认服务密钥; • 响应中的ETAG不是对象数据的MD5; • 可以在控制台创建、轮换或者禁用主密钥; • 用户需要实现开通KMS服务; • 使用“服务端加密-KMS托管主密钥”加解密对象时,会产生一定的KMS请求调用费用; • 用于加密数据的数据密钥也会被加密,并且作为Object的元数据信息一并存储; • KMS托管密钥的服务器端加密方式仅加密对象数据,不会加密任何对象的元数据; 目前以下操作,支持在请求中携带x-oss-server-side-encryption 以及X-oss-server-side-encrpytion-key-idHeader头: • Put Object: 简单上传 • Copy Object: 复制Object • Initiate Multipart Upload: 通过服务器端加密存储的object时,以下API请求中OSS会返回x-oss-server-side-encryption头以及X-oss-server-side-encrpytion-key-id: • Put Object • Post Object • Copy Object • Initiate Multipart Upload • Upload Part • Complete Multipart Upload • Get Object • Head Object 2.2使用由OSS完全托管加密密钥的服务器端加密(SSE-OSS) 服务器端加密是为了保护静态数据,使用OSS完全托管加密密钥的服务器端加密,采用了诸多强安全措施进行加密。当用户创建对象时(即上传新对象或者复制现有对象),只需要在请求中携带x-oss-server-side-encryption标头,并且指定其值为AES256。即可实现OSS完全托管加密密钥的服务器端加密。OSS使用AES256加密方式加密客户的数据,作为额外的保护,系统采用CMK主密钥加密密钥本身。 以下操作,支持在请求中携带这些HTTP Header: • Put Object: 简单上传 • Copy Object: 复制Object • Initiate Multipart Upload: 使用multipart upload上传大型对象时,可以通过为每个分段上传请求添加x-oss-server-side-encryption标头来指定服务器端加密。调用copy object时,无论原对象是否已经加密,都不会加密目标对象,除非显示的在拷贝操作中指定了x-oss-server-side-encryption请求头。 3.使用客户端(CSE)加密保护数据 客户端加密是指将数据发送到OSS之前在用户本地进行加密,对于数据加密密钥的使用,目前支持如下两种方式: 使用KMS托管用户主密钥(CSE-KMS) 使用用户自主管理密钥(CSE-C) 3.1使用KMS托管用户主密钥(CSE-KMS) 当使用KMS托管用户主密钥用于客户端数据加密时,无需向OSS加密客户端提供任何加密密钥。只需要在上传对象时指定KMS用户主密钥ID(也就是CMK ID)。其具体工作原理如下: 上传对象:--通过使用CMK ID,客户端首先会向KMS发送一个请求,申请1个用于加密对象的数据密钥(Data key)。作为响应,KMS会返回一个随机生成的数据明文密钥(Data key),以及数据密文密钥(Encrypted data key); 本地加密数据:--本地客户端接收到KMS返回的数据明文密钥(Data key)以及数据密文密钥(Encrypted data key)后,将使用数据明文密钥(**Data key)进行本地加密,并且将加密后的对象以及数据密文密钥(Encrypted data key)上传至OSS; 下载对象:--客户端首先会从OSS服务端下载加密的对象以及作为对象元数据存储的数据密文密钥(Encrypted data key)。 解密数据:客户端将数据密文密钥(Encrypted data key)以及CMK ID发送至KMS服务器。作为响应,KMS将使用指定的CMK解密,并且将数据明文密钥(Data key)返回给本地加密客户端; 注意: • 本地加密客户端为每一个上传的对象获取一个唯一的数据加密密钥; • 为了保证数据的安全性,建议CMK定期轮换或者更新; • 客户需要维护CMK ID与对象之间的映射关系; 3.2使用用户自主管理密钥(CSE-C) 使用用户自主管理密钥,需要用户自主生成、保管加密密钥。当用户本地客户端加密时,由用户自主上传加密密钥(对称加密密钥或者非对称加密密钥)至本地加密客户端。其具体加密过程如下: 上传对象:--用户首先向本地加密客户端提供1个用户主密钥(对称密钥或者非对称密钥)。客户端只使用此主密钥加密其随机生成的数据密钥。该过程如下: OSS本地加密客户端会在本地生成一个一次性的对称密钥(Data Key)。它将用于加密单个对象(针对每个对象,客户端都会随生成1个数据密钥); 客户端使用“数据密钥(Data key)”加密对象; 客户端使用用户提供的主密钥来加密“数据密钥(Data key)”; 客户端会将加密的数据密钥(Encrypted Data Key)作为对象元数据的一部分上传至OSS。 下载对象:--下载对象时,客户端首先从OSS下载加密的对象以及元数据。通过使用元数据中的材料,客户端将授权会确定使用哪个主密钥来解密加密的数据密钥(Encrypted Data Key)。客户端解密后的数据密钥(Data Key)来解密对象。 注意: •OSS本地加密客户端不会将用户主密钥以及未加密的数据发送至OSS。所以,请务必妥善保管加密密钥,如果密钥丢失,将无法解密数据; • 数据密钥(Data Key)由本地加密客户端随机生成;
第一章:概述 阿里云对象存储OSS提供弹性、海量的存储空间。但根据相关法规和服务条款,禁止用户使用对象存储OSS分享涉黄、涉政、涉恐类有害信息。若阿里云发现用户使用对象存储OSS产品分享违规内容,阿里云立即将该Bucket切入沙箱,情节严重的用户将追究法律责任。 第二章:如何针对OSS开通内容违规检测 若用户的业务系统中有可能存在违规图片、视频。为了保证用户Bucket的SLA,可以针对该Bucket开通“内容安全”服务。阿里云内容安全服务定期针对选中的Bucket进行扫描,有效的降低涉政涉黄内容的风险。 如下是开通“内容安全”的流程:开通内容安全检测 第三章:如何解封“因涉黄、涉政等内容而切入沙箱的Bucket” 用户通过阿里云对象存储OSS传播涉黄、涉政等内容,也会导致Bucket切入沙箱,情节严重的场景下会导致整个账号被拉黑。若用户的Bukcet被拉入沙箱,请按照如下流程进行处理:OSS沙箱处理流程 已被列入黑名单的用户,针对现有的Bucket部署阿里云“内容安全”产品,并通过工单进行申请。阿里云可在有限场景下支持将账号移出黑名单列表。
阿里云对象存储OSS现已经全面支持“对象版本管理”特性。该功能适用于所有的存储类型以及区域。当Bucket启用该特性后,“对象版本管理”功能可以保护和恢复误删除、误覆盖的数据。 对象存储OSS“版本管理”具有如下特点: 提供“应用级”数据保护,可防止文件意外覆盖:当Bucket开启版本管理特性后,该Bucket内对象的每次修改、删除操作,OSS都会生成对应的历史版本。授权的用户可以通过控制台、API、SDK等方式查询、下载以及恢复指定的历史版本 提供“回收站”功能,支持恢复已删除的数据:在启用“版本管理”特性的Bucket中删除对象,OSS会针对该对象生成一个特殊的历史版本—“删除标记”,标识该对象已经被“逻辑”删除。用户可以在控制台上直观的查看到所有“被删除”的对象。同时结合生命周期策略,还可以自主管理历史版本的保存时间 结合“跨区域复制”特性,阿里云OSS能够实现云上数据异地容灾:结合跨区域复制功能,源端Bucket中新增、修改的文件都会异步复制到容灾Bucket。当源端数据中心发生灾难时,用户可以在容灾中心恢复任意时间点的数据 “对象版本管理”是数据保护策略的一种方式,可以防止数据意外丢失。如果您的数据存在被应用程序或其他用户意外修改和删除的风险。我们建议您尽快启用“对象版本管理”特性。
概述 对象存储OSS现已全面支持WORM特性,允许用户以“不可删除、不可篡改”方式保存和使用数据。目前OSS多种强合规策略类型,用户可针对Bucket设置基于时间的保留策略,在对象的过期时间到期之前,包括根账号在内的任何用户都无法直接删除对象和策略,同时OSS也提供基于LegalHold的策略类型,用户可根据实际需求灵活选择策略类型。当前OSS合规策略适合于所有的存储类型,例如标准存储、低频存储、归档存储。用户可通过生命周期策略进行存储类型转化,在保证合规性的前提下,将数据存在最具成本效益的存储类型中。 场景 阿里云对象存储OSS现已全面支持WORM特性。允许用户以“不可篡改、不可删除”的方式保存和使用数据。这非常适用于金融、保险、医疗、证券等行业,第三方服务提供商可以基于对象存储OSS搭建”云上数据合规存储空间“。 典型的应用场景如下: 法规遵从:目前OSS是国内唯一通过Cohasset Associates审计认证的云服务,可满足严格的电子记录保留要求。例如,EC Rule 17a-4(f)、FINRA 4511、 CFTC 1.31等合规要求 合规保留(LegalHold):面对法律诉讼等场景,阿里云可以永久以不可删除、不可篡改的方式保存数据,直到诉讼期结束,这可以借助于对象存储OSS的LegalHold策略 对象存储OSS合规保留策略支持如下功能: 基于时间的保留策略:用户可以设置基于时间的保留策略。当策略锁定后,用户可以在bucket中上传和读取,但不可以修改或删除数据。对象的保留时间到期后,可以删除对象 基于LegalHold保留策略:如果在不确定具体的保留周期,用户可以设置基于LegalHold的保留策略。当合规保留策略设定后,用户可以在Bucket上传和兑取数据,但是不可修改或者删除数据。授权的用户可以删除基于LegalHold策略,当LegaHold策略被删除后,该Bucket将退出WORM保护模式 支持所有的存储类型:对象存储OSS的合规保留策略适用于所有的存储类型。即使Bucket进入WORM保护模式,用户可以设置生命周期策略进行存储类型转化,以降低实际存储成本 对象存储OSS的合规保留策略适用于所有的Region、并且兼容现有的Bucket。目前WORM策略已经在深圳区域进行公测发布,欢迎各位使用!
第一章:阿里云OSS Bucket默认加密方式介绍 阿里云OSS支持通过API、SDK、工具以及控制台等方式设置Bucket的默认加密方式。当Bucket设置服务端加密后,具有相应权限的用户上传文件到该Bucket时,自动对这些对象进行加密。Bucket默认加密方式适合于当前和新创建的Bucket。当使用服务端加密时,OSS在将数据保存到阿里云数据中心磁盘之前对其进行加密,并且在下载对象时自动进行解密。 使用OSS托管密钥加密,不会产生额外的费用。但是,使用KMS密钥进行加密时,会产生KMS使用以及相关API调用的费用。OSS服务端加密方式支持设置OSS托管密钥(SSE-OSS)、KMS托管密钥(SSE-KMS)以及KMS的BYOK密钥。 目前该功能已经在美东Region进行公测。如需进行测试,请联系阿里云技术支持或者工单咨询。 第二章:如何为Bucket设置服务端加密方式 2.1使用OSS控制台设置Bucket默认加密方式 当用户创建Bucket时,可以设置Bucket默认加密方式。针对已经存在的Bucket,用户可以在“基础设置”中修改Bucket的默认加密方式。 具体设置步骤如下:1.登录OSS控制台,选择需要设置的Bucket。切换至“基础设置”页面;2.选择“服务端加密”,如下所示: 3.目前服务端加密方式有如下3种: 无:不设置Bucket默认加密方式。若用户没有在PUT object请求标头中设置对象的加密方式,默认该对象以明文的方式存在OSS集群; AES256:使用阿里云OSS默认托管的密钥进行加密; KMS:KMS有2种加密方式: 1.alias/acs/oss:这是由OSS托管在KMS服务的密钥,默认所有的用户都可以使用OSS托管的KMS密钥进行加密; 2.CMK ID:支持用户使用指定的KMS密钥进行加密; 2.1.1相关操作授权 说明:针对OSS的每个操作均需要取得授权。如下是主要步骤的RAM 授权;1.STEP1:设置Bucket默认加密方式: 需要具有"Put Bucket Encryption"以及"Get Bucket Encryption"权限; 默认根账号以及具有“AliyunOSSFullAccess”、“AdministratorAccess”权限的账号默认具有如上2个权限; 若使用子账号登录控制台,则需要RAM Policy给当前用户授予如上2个权限; 2.STEP2:选择服务端加密合适的密钥: 由于AES256、以及OSS托管的KMS密钥的所有权限是属于阿里云OSS服务。因此,用户无需授权就可以使用AES256以及OSS托管的KMS密钥进行加解密操作; 若用户使用指定的CMK ID进行加密。那么,当前进行操作的子账号必须具备“ListKeys”、“Listalias”、“ListAliasesByKeyId”以及“DescribeKeys”。具体RAM policy策略如下: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "kms:List*", "kms:DescribeKey" ], "Resource": [ "acs:kms:*:1416614965936597:*" ] } ] } 说明:如上策略允许用户查看当前reigon下所有合适的CMK ID ,但是仅支持选择1个KMS 密钥; 3.STEP3:子账号上传文件至指定的Bucket: 当配置Bucket 服务端默认加密方式后。用户上传文件到该Bucket的对象,将采用Bucket的默认服务端加密方式进行加密,除非用户在上传文件时特别设置了该对象的加密方式。 Bucket的服务端加密方式设置为AES256或者默认OSS托管的KMS密钥(alias/acs/oss),任何具有上传权限的对象都可以将对象上传至该Bucket,并且采用该Bucket的默认加密方式。若服务端的加密方式为KMS,并且使用了指定的CMK ID。那么用户上传对象至该Bucket时,需要具有对应CMK ID的加密权限。否则该对象因为没有权限调用KMS加密权限,而导致上传失败。如下是给子账号设置具有对应CMKID加密权限的RAM policy示例: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "kms:List*", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": [ "acs:kms:*:1416614965936597:*" //当前示例表示允许调用该账号下所有的KMS密钥,如果仅限制使用某个KMS,此处可输入对应的CMK ID ] } ] } 4.STEP4:子账号从Bucket中下载加密的对象: 当设置了Bucket默认服务端加密方式后,上传到该Bucket的对象默认都会进行服务端加密。可以授权子账号从该Bucket下载对象。若Bucket的服务端加密方式是AES256以及OSS默认托管的KMS密钥(该密钥别名是alias/acs/oss),此时具有下载权限的用户都可以从该Bucket下载对象。OSS会自动对加密的对象进行解密,并且将明文对象返回给用户。 若该Bucket设置了使用指定KMS的密钥进行加密,那么下载该Bucket内对象的用户除了需要具备get object权限外,还需要具有指定KMS密钥对应的解密权限。若该子账号仅具有get object权限,而没有对应KMS的解密权限(decrypt权限),那么用户下载文件时也会提示下载失败。阿里云OSS不会将加密后的密文对象直接返回给用户。如下是给子账号设置具有KMS解密权限的RAM policy: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "acs:kms:*:1416614965936597:*"//该示例表示子账号具有当前所有KMS的解密权限。若要针对某个KMS密钥进行解密,此处可输入对应的CMK ID ] } ] } 说明:下载使用了指定KMS密钥加密的对象是需要额外配置相关KMS权限。所以,当您的AK被泄露后,您可以通过禁用KMS或者修改kms相关policy,已拒绝所有用户对该Bucket的请求。 2.2使用REST API方式设置Bucket默认加密方式 如下,您也可以使用API方式设置Bucket 服务端默认加密方式: 使用 PUT Bucket Encryption 接口设置Bucket的默认服务端加密方式(AES256或者KMS); 使用 DELETE Bucket Encryption接口禁止对象的默认加密。禁用默认加密后,OSS仅在PUT请求包含加密信息时加密对象 使用GET Bucket Encryption接口查看该Bucket的默认加密方式; 2.3使用工具设置Bucket默认加密方式 当前还不支持SDK以及工具方式设置Bucket 默认加密方式,预计2019年上半年支持该特性。
第一章:用户使用场景介绍 阿里云控制台提供了各个产品相关图形化配置,并且功能比较齐全。对于用户来说,学习成本低、易操作、易上手。因此,绝大多数用户使用主账号登录控制台进行日常的运维管理操作。由于主账号对其名下的所有阿里云资源都拥有完全控制的权限,一旦主账号的登录密码泄露,该账号下的资产将面临极大的损失,甚至有可能被他人恶意使用而造成相关法律风险。 因此,我们建议您禁用主账号进行相关操作,而是通过授权子账号的方式进行运维和开发管理。而对于不得不使用控制台进行操作的场景,我们建议您对账号启用MFA,以提高账号的安全性。 第二章:为主账号/子账号启用MFA 为主账号/子账号启用MFA的相关操作方法请参见:账号设置MFA操作方法 第三章:为子账号配置RAM policy 已拒绝非MFA认证的操作请求 当为主账号以及子账号启用MFA后,用户每次登录控制台的操作都需要输入MFA安全码。因此,可以保证控制台相关操作的安全。但是SDK、API以及工具的相关操作默认不传递MFA参数。因此,对于启用了MFA认证的账号,仍然使用AK信息,不通过MFA二次认证而继续使用SDK、API以及工具操作OSS相关资源。为了实现拒绝子账号所有非MFA二次认证的操作请求,需要对子账号额外赋予RAM Policy。具体RAM Policy策略模板如下: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:*" ], "Condition": { "Bool": { "acs:MFAPresent": [ "true" ] } } } ] } 设置如上RAM policy策略后,该账号的所有请求操作都需要进过MFA进行二次认证。因此账号登录控制台,输入MFA安全码后,就可以进行正常操作。但是该用户如果使用API、SDK或者工具进行操作,就会提示授权失败如下所示: D:\5-AK账号\ossutil64>ossutil64.exe ls oss://test-hangzhou-2025/ -e http://oss- cn-hangzhou.aliyuncs.com Error: oss: service returned error: StatusCode=403, ErrorCode=AccessDenied, Erro rMessage=The bucket you visit is not belong to you., RequestId=5C52AB7E880904877 DF82E2E, Bucket=test-hangzhou-2025! 第四章:FAQ Bucket Policy的条件参数是否支持设置"MFAPresent"参数? 当前不支持。后续规划支持该特性; 对于有API、SDK或者工具操作是否支持指定MFA参数? 当前不支持;
一、阿里云提供完善且全面的权限管控体系 阿里云提供业内最为完善的权限管控体系,涵盖了“基于资源的权限管理”以及“基于用户的权限管理”层面。并且阿里云“访问控制”采用基于ABAC(Attribute Based Access Control)而不是简单的RBAC(Role Based Access Control),用户可以访问者的当前环境属性(例如,current time、source ip、HTTP访问方式、prefix等参数)判断是否具有相应的操作权限。如下是阿里云OSS的权限管控体系。 Bucket ACL以及Object ACL是一种非常粗粒度的权限管理方式。当Bucket或者Object设置为“public-read”、“public-read/wirte”时,任何用户都可以访问该资源,并且不需要进行身份认证,这有可能导致您数据外漏、外网下行流量激增,甚至匿名用户有可能向您“public-read/write”的Bucket内写入非法数据,导致您面临法律风险。 【注意】:不建议您设置“public-read”、“public-read/write”访问权限。 签名URL:阿里云提供资源级别的签名URL访问方式。用户接收到该签名URL链接后,在指定的时间内都可以访问该对象。阿里云签名URL能够提供一定程度的权限管控,但是该签名URL分享到外部后,也有可能造成数据泄漏。因此,我们建议您在内部使用签名URL或者结合其他安全管控手段并行使用; Bucket Policy:阿里云提供的一种基于资源的ABAC权限管理方式。用户能够在OSS控制台实现一键配置。我们建议您通过Bucket Policy进行日常权限管理; RAM Policy:阿里云提供了一种基于用户的ABAC权限管控方式,RAM policy功能强大,且配置灵活。用户可以根据实际需要创建精细化权限管控策略。并且支持授予给指定的用户、用户组、角色。我们建议您通过RAM Policy创建个性化权限管理策略; 阿里云提供全面且完善的权限管控措施。我们建议用户日常通过子账号进行RAM Policy或者Bucket Policy授权,而避免直接操作根账号 。但是,由于RAM policy学习成本高,需要编辑个性化RAM policy策略脚本,因此相当一部分用户仅仅使用了阿里云提供的默认RAM policy 授权模板(该授权模板权限过大,并不能实现对象级别细颗粒度授权),而不是自行编写精细化RAM 授权策略。 为了让更多的用户能够使用上阿里云强大的权限管控能力。阿里云OSS推出了图像化Bucket Policy策略,普通用户可以在OSS控制台进行日常的权限分配,而不需要编辑RAM policy授权脚本。目前OSS的Bucket Policy可以覆盖用户日常80%以上的授权场景。 二、【Bucket Policy】日常使用场景介绍 2.1【Bucket Policy】介绍 Bucket Policy是一种基于资源的管控策略。您可以选中指定的Bucket或者prefix进行授权操作。当前您可以通过OSS控制台进行授权,后续阿里云将逐步在API、SDK层面支持该特性。如下是Bucket Policy的参数说明: 字段 值 描述 授权资源 1. 若选中某个对象,直接点击“授权”,则此处会自动填充对应资源的路径;2. 若点击“操作授权”,则需要输入对应的资源路径。 1.若资源为bucket时,“授权操作”作用于bucket以及bucket内所有子对象;2. 若资源为对象或者目录,“授权操作”作用于该对象或者该目录下所有的子对象; 授权用户 输入格式:1.授权给账号:输入对应账号ID或者选择子账号username;2.授权给子用户:输入对应子用户的ID Bucket Policy支持跨账号授权;若授权给匿名用户,则勾选“所有用户”; 授权操作 为了简化授权过程,oss针对常见的授权场景进行了简化操作,目前只提供“只读”、“读写”以及“完全控制”、“拒绝访问”操作。 1.“只读”2.“读写”;3. “完全控制” 4."拒绝访问" 条件 IP等于、IP不等于 当输入多个IP地址或者IP地址段时,用英文逗号分隔; 条件 HTTP、HTTPS 设置请求的访问方式; 如下我们将介绍几个Bucket Policy的典型使用案例。 2.2通过Bucket Policy进行日常权限管理 2.2.1场景1:向多个子账号授予读写访问权限 如下是向多个子账号授予读写访问权限的操作界面。若针对当前根账号下的多个子账号进行授权,那么直接按照username进行勾选。 说明: 目前只有Bucket的Owner才能进行“Bucket Policy”设置操作。也就说该账号必须拥有Bucket的“完全控制”权限,或者拥有默认的RAM “AliyunOSSFullAccess”权限; 选择子账号授权时,当前操作的用户必须拥有“ListUsers”权限。默认根账号拥有该权限。若当前操作的用户没有"ListUsers"权限,则需要通过RAM Policy给当前进行Bucket Policy授权操作的账号进行RAM 授权。子账号拥有ListUsers权限的RAM 授权模板; { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "ram:ListUsers" ], "Resource": [ "*" ], "Condition": {} } ] } 2.2.2场景2:授权子账号针对目录拥有只读权限 下面的示例策略向子账号“test-user”、“tmp-user”针对figo这个目录授予“只读访问”权限。绝大多数用日常的授权场景都是向指定的目录授予“读写”、“只读”访问权限。因此通过Bucket Policy基本上可以涵盖绝大多数常规的授权操作。我们强烈建议您通过Bucket Policy针对子账号授予细颗粒度访问权限,而不是使用默认的RAM policy模板。 说明: 若当前进行Bucket Policy配置操作的账号无法获得"ListUsers"权限,也可以直接输入被授权账号的UID; 当针对目录授权时,您需要输入目录的绝对路径,并且以/*结尾; 当针对具体的对象授权时,您需要输入该对象的绝对路径以及对象名称即可。此处不需要以/*结尾。如下所示: 2.3场景3:通过Bucket Policy进行跨账号授权 如下Bucket Policy示例策略向其他阿里云账号授予test-hangzhou-2025这个Bucket的只读访问权限。由于跨账号授权无法直接获取“listusers”权限。因此,只能输入对应账号的UID。 说明:若针对多个账号进行授权,请直接输入对应账号的UID,并换行输入下一个账号的UID; 3.Bucket Policy高级使用场景介绍 3.1场景4:限制对特定IP地址的访问权限 以下示例向指定的子账号授予对Bucket的只读访问权限,但是访问请求必须来自于条件中指定的IP地址段。当前Bucket Policy仅支持IPV4的条件授权。Bucket Policy条件参数中使用“IpAddress”、“NotIpAddress”以及“SoureceIP”条件值进行过滤。 3.2场景5:向匿名用户授予访问权限 以下授权策略向任何公共匿名用户授权针对Bucket的只读访问权限。此权限允许任何人访问该Bucket内的对象数据。当您将Bucket 设置为网站并期望任何人都可以访问时,这非常有用。 特别注意:请谨慎使用针对匿名用户授予只读访问权限,这将导致您Bucket内对象数据能够被任何人公开的获取。强烈您不要授予匿名用户写入Bucket的权限。 4.Bucket Policy进阶使用场景介绍 4.1场景5:拒绝用户通过HTTP协议访问指定的Bucket 以下策略实现了拒绝所有用户(包括授权的用户以及未授权的匿名用户)通过HTTP协议访问指定的Bucket。我们建议您通过deny的方式拒绝HTTP的访问请求,而不是通过ALLOW方式允许HTTPS访问请求。 5.Bucket Policy与RAM policy关联关系 5.1Bucket Policy 与RAM Policy是什么关系? 补充关系:Bucket Policy可以完成跨账号授权、针对匿名用户授权、以及授予带IP条件限制的访问策略; Bucket Policy无法代替RAM Policy:例如Bucket Policy不支持递归授权; 5.2相比于RAM Policy,Bucket Policy有哪些优势? 操作灵活:直接在OSS控制台进行图形化操作,无需编写策略脚本; 授权简单:支持授权用户针对指定的Bucket进行权限管理操作,而无需授予整个RAM Policy编辑权限; 满足更多授权场景:支持跨账号授权、针对匿名用户授权、以及设置带IP条件限制的授权策略。
一、当前存在的问题 当前OSS支持用户使用HTTPS/HTTP协议访问Bucket。但由于HTTP存在安全漏洞。大型企业客户都要求使用HTTPS方式访问OSS,并且拒绝HTTP访问请求。 目前OSS可以通过RAM policy方式实现:限制某个用户、角色拒绝通过HTTP协议访问指定的Bucket和对象。但是RAM Policy是一种基于用户的授权方式,无法针对资源进行授权。也就是说无法针对Bucket或者对象级别,拒绝所有用户的HTTP请求。目前我们正在基于Bucket Policy开发该功能,后续用户可以直接通过Bucket Policy设置HTTPS访问策略。 二、通过RAM Policy实现“限制用户仅通过HTTPS方式访问OSS” 阿里云RAM Policy有丰富的Condition参数,可以限制对资源的访问。这里我们利用"Secure Transport"条件参数生成RAM Policy,以实现拒绝指定的用户通过HTTP方式访问Bucket。 Condition 功能 合法取值 acs:SecureTransport 是否是https协议 “true”或者”false” 2.1RAM Policy示例 为了简化配置,我们事先给账号赋予“AliyunOSSFullAccess”,然后模拟拒绝一切通过HTTP的请求。 添加“拒绝HTTP访问请求”RAM Policy。具体RAM Policy内容如下: { "Version": "1", "Statement": [ { "Effect": "Deny", "Action": [ "oss:*" ], "Resource": [ "acs:oss:*:*:*" ], "Condition": { "Bool": { "acs:SecureTransport": [ "false" ] } } } ] } 说明::如上Policy能够拒绝该用户通过HTTP方式访问OSS资源; 2.2用户通过HTTPS方式访问OSS进行测试 说明: 我们以Python SDK上传文件方式进行举例说明; 如下我们在脚本中指定访问路径为"https://oss-cn-beijing.aliyunc.com" ; 2.2.1通过HTTPS方式上传文件 python脚本示例如下: # -*- coding: utf-8 -*- import oss2 # 阿里云主账号AccessKey拥有所有API的访问权限,风险很高。强烈建议您创建并使用RAM账号进行API访问或日常运维,请登录 https://ram.console.aliyun.com 创建RAM账号。 auth = oss2.Auth('<yourAccessKeyId>', '<yourAccessKeySecret>') # Endpoint以杭州为例,其它Region请按实际情况填写。 bucket = oss2.Bucket(auth, 'https://oss-cn-beijing.aliyuncs.com', 'test-beijing-2018') # <yourLocalFile>由本地文件路径加文件名包括后缀组成,例如/users/local/myfile.txt bucket.put_object_from_file('02.txt', '002.txt') 执行结果如下: root@shanghai-02:~/figo# python putobject.py 2019-01-10 20:55:37,003 oss2.api [INFO] 140496922879744 : Init oss bucket, endpoint: https://oss-cn-beijing.aliyuncs.com, isCname: False, connect_timeout: None, app_name: , enabled_crc: True 2019-01-10 20:55:37,008 oss2.api [INFO] 140496922879744 : Put object from file, bucket: test-beijing-2018, key: 02.txt, file path: 002.txt 2019-01-10 20:55:37,009 oss2.api [INFO] 140496922879744 : Start to put object, bucket: test-beijing-2018, key: 02.txt, headers: {'Content-Type': 'text/plain'} 2019-01-10 20:55:37,212 oss2.api [INFO] 140496922879744 : Put object done, req_id: 5C3740C952FF5BAFB298BDDA, status_code: 200 说明:如上执行结果,表明文件已经上传成功; 2.2.2通过HTTP方式上传文件 说明:如下我们在脚本中指定访问路径为“http://oss-cn-beijing.aliyuncs.com” python脚本示例如下: # -*- coding: utf-8 -*- import oss2 # 阿里云主账号AccessKey拥有所有API的访问权限,风险很高。强烈建议您创建并使用RAM账号进行API访问或日常运维,请登录 https://ram.console.aliyun.com 创建RAM账号。 auth = oss2.Auth('<yourAccessKeyId>', '<yourAccessKeySecret>') # Endpoint以杭州为例,其它Region请按实际情况填写。 bucket = oss2.Bucket(auth, 'http://oss-cn-beijing.aliyuncs.com', 'test-beijing-2018') # <yourLocalFile>由本地文件路径加文件名包括后缀组成,例如/users/local/myfile.txt bucket.put_object_from_file('02.txt', '002.txt') 执行结果如下: root@shanghai-02:~/figo# python putobject.py 2019-01-10 21:14:37,499 oss2.api [INFO] 140697781880576 : Init oss bucket, endpoint: http://oss-cn-beijing.aliyuncs.com, isCname: False, connect_timeout: None, app_name: , enabled_crc: True 2019-01-10 21:14:37,501 oss2.api [INFO] 140697781880576 : Put object from file, bucket: test-beijing-2018, key: 02.txt, file path: 002.txt 2019-01-10 21:14:37,503 oss2.api [INFO] 140697781880576 : Start to put object, bucket: test-beijing-2018, key: 02.txt, headers: {'Content-Type': 'text/plain'} 2019-01-10 21:14:37,585 oss2.api [ERROR] 140697781880576 : Exception: {'status': 403, 'x-oss-request-id': '5C37453DDF97EBEDF4BDA095', 'details': {'HostId': 'test-beijing-2018.oss-cn-beijing.aliyuncs.com', 'Message': 'You have no right to access this object because of bucket acl.', 'Code': 'AccessDenied', 'RequestId': '5C37453DDF97EBEDF4BDA095'}} Traceback (most recent call last): File "putobject.py", line 10, in <module> bucket.put_object_from_file('02.txt', '002.txt') File "build/bdist.linux-x86_64/egg/oss2/api.py", line 481, in put_object_from_file File "build/bdist.linux-x86_64/egg/oss2/api.py", line 453, in put_object File "build/bdist.linux-x86_64/egg/oss2/api.py", line 1579, in __do_object File "build/bdist.linux-x86_64/egg/oss2/api.py", line 210, in _do oss2.exceptions.AccessDenied: {'status': 403, 'x-oss-request-id': '5C37453DDF97EBEDF4BDA095', 'details': {'HostId': 'test-beijing-2018.oss-cn-beijing.aliyuncs.com', 'Message': 'You have no right to access this object because of bucket acl.', 'Code': 'AccessDenied', 'RequestId': '5C37453DDF97EBEDF4BDA095'}} 说明: 当我们将上传endpoint设置为"http://oss-cn-beijing.aliyuncs.com" 时,上传文件失败。说明RAM Policy已经生效; 三、通过Bucket Policy实现“限制用户仅能通过HTTPS访问OSS资源” 以下策略实现了拒绝所有用户(包括授权的用户以及未授权的匿名用户)通过HTTP协议访问指定的Bucket。我们建议您通过deny的方式拒绝HTTP的访问请求,而不是通过ALLOW方式允许HTTPS访问请求。 说明: 目前RAM Policy仅能限制指定的用户通过HTTPS方式访问。OSS已经在Bucket Policy中支持设置"Secure Transport"参数,以实现限制所有用户通过HTTP方式访问指定的Bucket和对象。我们推荐您通过Bucket Policy方式实现仅通过HTTPS方式访问指定的OSS资源
1.Terraform简介 Terraform 是一个开源的自动化的资源编排工具,支持多家云服务提供商。阿里云作为第三大云服务提供商,terraform-alicloud-provider 已经支持了超过 90 多个 Resource 和 Data Source,覆盖20多个服务和产品,吸引了越来越多的开发者加入到阿里云Terraform生态的建设中。 HashiCorp Terraform 是一个IT基础架构自动化编排工具,可以用代码来管理维护 IT 资源。Terraform的命令行接口 (CLI) 提供一种简单机制,用于将配置文件部署到阿里云或其他任意支持的云上,并对其进行版本控制。它编写了描述云资源拓扑的配置文件中的基础结构,例如虚拟机、存储帐户和网络接口。Terraform 的命令行接口(CLI)提供一种简单机制,用于将配置文件部署到阿里云或任何其他支持的云并对其进行版本控制。 Terraform是一个高度可扩展的工具,通过 Provider 来支持新的基础架构。您可以使用Terraform来创建、修改、删除ECS、VPC、RDS、SLB等多种资源。 2.OSS的Terraform Module都能够提供哪些操作? 目前阿里云已经将OSS的module发布到了GitHub上。目前OSS提供的主要功能有Bucket管理,以及日常的文件对象管理。例如: Bucket 管理功能: 1.创建Bucket 2.设置Bucket ACL 3.设置Bucket CORS 4.设置Bucket Logging 5.设置Bucket 静态网站托管 6.设置Bucket Referer 7.设置Bucket Lifecycle Object管理功能: 1.文件上传 2.设置文件服务端加密方式 3.设置ACL 4.设置对象元数据信息 1.OSS Module在GitHub上下载地址:GitHub下载地址2.OSS Terraform Module介绍:Module介绍 接下来我们就从简单的示例 开始了解,Terraform是如何管理Bucket和文件对象。 3.安装Terraform 在使用Terraform的简单模板语言定义、预览和部署云基础结构前,您需要安装预配置Terraform。 【安装步骤】如下: 1.前往 Terraform官网 下载适用于您的操作系统的程序包;2.将程序包解压到/usr/local/bin。如果将可执行文件解压到其他目录,则需要将路径加入到全局变量:3.运行 terraform 验证路径配置。 将显示可用的Terraform选项的列表,类似如下所示,表示安装完成。 username:~$ terraform Usage: terraform [-version] [-help] <command> [args] 4.为提高权限管理的灵活性和安全性,建议您创建RAM用户,并为其授权。 **注意**:请不要使用主账号进行操作!!! 常见的terraform命令是 terraform init, terraform plan, terraform apply。 4.创建配置文件 需要为每个terraform项目创建1个独立的执行目录。所以,我们创建terraform-test目录。该目录下所有*.tf 文件都会被terraform加载,因此,在初始化配置之前需要有1个.tf文件。 mkdir terraform-test cd terraform-test Terraform在运行时,会读取该目录空间下所有.tf以及.tfvars 文件。因此,没有必要将所有配置信息写在1个配置文件中。用户可以按照实际用途将配置信息写入到不同的文件中。例如: provider.tf -- provider 配置 terraform.tfvars -- 配置 provider 要用到的变量 varable.tf -- 通用变量 resource.tf -- 资源定义 data.tf -- 包文件定义 output.tf -- 输出 Step1:如下我们将创建provider.tf 文件存放用户的身份认证信息。 provider "alicloud" { region = "cn-hanghzou" access_key = "your-access-key-here" secret_key = "your-secret-key-here" } 说明:以下示例中都会用到provider.tf文件,请不要删除该文件。此外,建议将AK信息单独存放到provider.tf文件,不建议将AK信息与对象操作放在同一个tf文件中。 Step2:我们以创建1个Bucket为例。如下我们创建1个test.tf文件,内容如下: resource "alicloud_oss_bucket" "bucket-acl"{ bucket = "figo-chen-2020" acl = "private" } 4.1配置文件介绍 4.1.1"alicloud_oss_bucket"介绍 您可以从该链接查看到bucket所有配置信息。 如果bucketfigo-chen-2020不存在,则运行 terraform apply 后将自动创建该bucket。若已经存在Bucket,则强制进行重命名操作。 注意:资源的操作行为与Terraform的状态有关。若无,则创建该Bucket,若有,则强制进行重命名操作。重命名操作会被拆分为“删除+新建”2个操作步骤。 5.初始化工作目录 新建terraform工作目录,并创建配置文件后。terraform apply 、 terraform plan 等命令是无法执行的。需要先进行初始化操作。 Terraform init 执行 terraform init命令后,会在当前目录创建.terraform目录。并依据 *.tf文件中的配置信息下载对应的插件。 示例输出信息如下: root@figo-hangzhou:~/terraform-test# terraform init Initializing provider plugins... - Checking for available provider plugins on https://releases.hashicorp.com... - Downloading plugin for provider "alicloud" (1.24.0)... The following providers do not have any version constraints in configuration, so the latest version was installed. To prevent automatic upgrades to new major versions that may contain breaking changes, it is recommended to add version = "..." constraints to the corresponding provider blocks in configuration, with the constraint strings suggested below. * provider.alicloud: version = "~> 1.24" Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary. 6.执行Terraform命令 1. 新建配置文件,并执行初始化后,就可以执行相关Terraform命令了。Terraform提供了预览功能,允许在正式执行之前查看将要执行那些操作。 terraform plan 输出信息如下: root@figo-hangzhou:~/terraform-test# terraform plan Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: + alicloud_oss_bucket.bucket-acl id: <computed> acl: "private" bucket: "figo-chen-2020" creation_date: <computed> extranet_endpoint: <computed> intranet_endpoint: <computed> location: <computed> logging_isenable: "true" owner: <computed> referer_config.#: <computed> storage_class: <computed> Plan: 1 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run. 2.若要执行工作目录中的配置文件,请运行如下命令: terraform apply 输出信息如下: root@figo-hangzhou:~/terraform-test# terraform apply An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: + alicloud_oss_bucket.bucket-acl id: <computed> acl: "private" bucket: "figo-chen-2020" creation_date: <computed> extranet_endpoint: <computed> intranet_endpoint: <computed> location: <computed> logging_isenable: "true" owner: <computed> referer_config.#: <computed> storage_class: <computed> Plan: 1 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes alicloud_oss_bucket.bucket-acl: Creating... acl: "" => "private" bucket: "" => "figo-chen-2020" creation_date: "" => "<computed>" extranet_endpoint: "" => "<computed>" intranet_endpoint: "" => "<computed>" location: "" => "<computed>" logging_isenable: "" => "true" owner: "" => "<computed>" referer_config.#: "" => "<computed>" storage_class: "" => "<computed>" alicloud_oss_bucket.bucket-acl: Creation complete after 1s (ID: figo-chen-2020) Apply complete! Resources: 1 added, 0 changed, 0 destroyed. 如上已经成功的创建了 figo-chen-2020 这个bucket,并且ACL是Private。 3.若要显示删除已存在的资源,请运行如下命令: terraform destroy 7.Bucket相关配置操作示例 7.1设置Bucket Access-log示例: resource "alicloud_oss_bucket" "that"{ bucket = "figo-chen-2019" acl = "private" } resource "alicloud_oss_bucket" "bucket-logging" { bucket = "figo-chen-2018" acl = "private" logging { target_bucket = "${alicloud_oss_bucket.that.bucket}" target_prefix = "log/" } logging_isenable = true } 说明:若Bucket不是通过terraform创建。则通过 如下命令导入现有的Bucket。 terraform import alicloud_oss_bucket.bucket bucket-name 1.编辑mail.tf文件,在此文件中编辑导入Bucket的ACL等其他信息。例如: resource "alicloud_oss_bucket" "bucket"{ bucket = "test-hangzhou-2025" acl = "private" } 2.执行terraform import命令,如下是导入“test-hangzhou-2025”这个bucket的命令: terraform import alicloud_oss_bucket.bucket test-hangzhou-2025 8.其他Bucket配置操作示例: 其他配置操作示例请参考:Bucket配置操作参考 9.Object相关配置操作示例 Object相关配置操作请参考:Object配置示例参考
第一章:OSS沙箱说明 阿里云OSS不承担网络攻击的防护义务。用户账号下的Bucket遭受攻击后,OSS会自动将用户的Bucket切入到沙箱。沙箱中的Bucket仍然可以正常响应请求,但是用户有可能明显感受到该Bucket服务质量的下降。 注:沙箱介绍:沙箱介绍 第二章:借助于高防IP,OSS抵御DDOS攻击 2.1 方案1:绑定域名+高防IP方式防御DDOS攻击 如果您的业务有可能遭受DDOS攻击,可以按照如下方式进行配置。 绑定OSS自定义域名: 配置参考:[绑定自定义域名]; 购买高防IP,并将高防IP绑定到第一步设置的自定义域名。配置参考:[设置高防IP];注意:请根据业务实际情况,购买对应的弹性防护带宽; - “防护网站”:填写用户自定义的域名; - “协议类型”:根据实际访问请求方式,合理配置; - “源站IP/域名”:此处填写OSS的默认域名; 2.2 方案2:ECS反向代理+高防IP方式抵御DDOS攻击 因安全因素,Bucket默认域名解析的IP是会发生随机变化。对于期望使用固定IP方式访问的客户来说。推荐使用通过ECS搭建反向代理方式进行访问。因此,ECS上的EIP可以绑定高防IP以抵御DDOS攻击和CC攻击。具体可以按照如下方式进行配置: ECS反向代理方式访问OSS:详细配置可参考:[OSS反向代理访问方式配置]; 建议ECS部署在与OSS同一个region内; 将ECS绑定高防IP:[ECS绑定高防IP]; ECS上的EIP绑定自定义域名; 1.“防护域名”:此处填写用户自定义的域名; 2.“协议类型”:此处根据实际需求,选择对应的访问方式。OSS默认提供的是Restful API访问方式; 3.“源站IP/域名”:此处填写ECS上的公网IP; 2.3方案优劣势分析 方案名称 方案1:绑定域名+高防IP方式 方案2:ECS反向代理+高防IP方式 优势 配置简单--支持控制台图形化设置 1.解决方案具有通用性--能够为已进入沙箱和未进入沙箱的Bucket提供防护能力;2.适合于通过固定IP访问OSS的场景; 劣势 应用场景有局限性--只能针对未进入沙箱的Bucket提供防护 1.配置复杂。需要用户自定搭建nginx反向代理;2.方案成本高--需要额外购买ECS搭建反向代理; 第三章:已进入沙箱的Bucket如何进行防护? 场景1. 若用户账号下的Bucket曾多次遭受攻击。那么,该用户后续新建的Bucket默认也会进入沙箱。此时,针对新建Bucket的安全访问措施如下: 1.购买DDOS防护产品; 2.通过工单系统提交“新建Bucket默认不进入沙箱申请”; 3.申请通过后,按照“2.1章节 绑定域名+高防IP方式防御DDOS攻击”; 场景2. 针对已经进入沙箱的Bucket。阿里云不提供迁出服务。因此,针对已经进入沙箱的Bucket,建议按照方式2配置安全防护措施; 【注意】:建议在Bucket所在的Region搭建ECS,并且proxy_pass 填写bucket内网域名地址;
1.当前存在的问题 无法通过固定的IP方式访问OSS:阿里云OSS通过Restful API方式对外提供服务。最终用户通过OSS默认域名或者绑定的自定义域名方式访问(例如:https://your_bucketname.oss-cn-hangzhou.aliyuncs.com/your_object ) 。您可以通过域名解析的方式获取某个Bucket域名对应的临时IP,但是由于阿里云OSS自身安全机制,Bucket域名对应的IP是会随机发生变化的。因此,您无法获取某个Bucket对应的长期有效IP地址。而某些企业由于安全机制,需要在出口防火墙配置策略,以限制内部员工和业务系统只能访问指定的公网IP。 互联网用户无法直接访问金融云OSS:由于金融云网络架构限制,金融云内网类型的Bucket只能在金融云内部访问。不支持在互联网上直接访问金融云内网类型Bucket; 2.基于ECS搭建反向代理方式访问OSS 针对如上问题,我们采用了“基于ECS搭建反向代理方式访问OSS”。 上图是基于“ECS搭建反向代理”的逻辑示意图,其主要实现机制如下: 在Bucket所在的Region创建ECS; 在同Region创建SLB(可选)。为了提高ECS的可用性,可以搭建多台ECS作为集群对外提供服务(可选); 在ECS上部署Nginx或者Apache作为反向代理服务; 3.配置操作步骤 3.1演示前提 1. ECS *1; a) 所在Reigon: cn-shanghai b) 操作系统版本: Ubuntu 16.04(64位); 2. Bucket *1; a) 所在Reigon: cn-hongkong b) Bucket名称: test-hongkong-2025 3. 此次配置仅做演示说明。因此,没有配置SLB; 4. 反向代理服务: a) Nginx 3.2在ECS上安装Nginx 3.2.1安装Nginx sudo apt-get install nginx 默认安装位置: /usr/sbin/nginx 主程序 /etc/nginx 存放配置文件 /usr/share/nginx 存放静态文件 /var/log/nginx 存放日志 3.2.2配置Nginx 1.配置Nginx: sudo vi /etc/nginx/nginx.conf 2.请在config文件中的HTTP模块添加如下内容: upstream mysvr { server 127.0.0.1; #default_server1; server 101.132.39.231; #default_server2; server 172.19.158.170; #default_server3; } server { listen 80; server_name 101.132.39.231; #对外提供反向代理服务的IP; location / { index http://test-beijing-2019.oss-cn-beijing.aliyuncs.com/index.html; #可选; proxy_pass http://test-hongkong-2025.oss-cn-hongkong.aliyuncs.com; #如果主机与Bucket不在同一个区域,需使用外网; } } 3.2.3重启Nginx服务 1.启动Nginx服务: sudo nginx –t 2.重启nginx服务: nginx -s reload 3.4测试 如下,我们测试访问test-hongkong-2025这个Bucket下某个文件: root@iZuf698rtvi9j9uskgv84tZ:/etc/nginx# curl http://101.132.39.231/011.txt 002 003 004 005 006 007 008 009 如上所示,基于ECS搭建反向代理服务的方式,能够对外提供固定IP的访问方式。
1. 当前存在的问题: 金融云由于等保要求,不能直接将闪电立方设备寄送到金融云机房。因此,我们还不能通过闪电立方的方式直接迁移数据至金融云OSS。但是金融云提供了另外一种类型的Bucket-金融云公网Bucket。金融云公网Bucket类似于公共云,能够被互联网直接访问。因此,是否可以借助于金融云公网OSS进行中转? 2.总体思路: 由于金融云内网只能在金融云内部访问。外部互联网无法访问。但是金融云公网Bucket类似于与公共云的OSS,允许VPC以及经典网络以及互联网访问。因此我们的思路是在金融云内部搭建1个ECS服务。该ECS服务是能够访问金融云内网Bucket,同时该ECS也是能够访问金融云公网OSS。注意:金融云的ECS可以直接访问互联网,但是互联网的end user是不能直接访问金融云内部ECS的。需要通过SLB中转。 此处我们的思路是这样的: 创建金融云ECS,同时创建金融云内网OSS; 在该金融云ECS上部署ossimport工具,通过ossimport工具将金融云公网Bucket内容 迁移至 金融云内网Bucket; 说明: 测试环境下:该方式的单台ECS迁移速度可以达到50MB/s; 若实际测试环境速度达不到客户要求,可以创建多个ECS服务器,然后集群版ossimport, 说明:整个迁移过程都不走公网,不会产生流量费用!!! 3.演示示例: 如下的示例均是基于这个场景,实际配置过程中请根据实际客户场景进行修改; • ECS 服务器:ubuntu16.04 - ECS endpoint: 华东2金融云 • 金融云内网OSS: (目的端) - Bucket名称:test-shagnhai-finane-in - Endpoint: oss-cn-shanghai-finance-1-internal.aliyuncs.com • 金融云公网OSS:(源端) - Bucket 名称:test-shanghai-finance-pubb - 内网Endpoint:oss-cn-shanghai-finance-1-pub-internal.aliyuncs.com - 外网Endpoint:oss-cn-shanghai-finance-1-pub.aliyuncs.com 3.1 Step1:在上海金融云开通部署ECS 1.下载ossimport(此处下载ossimport集群版): a) 命令:wget http://gosspublic.alicdn.com/ossimport/distributed/ossimport-2.3.2.tar.gz?spm=a2c4g.11186623.2.1.9EPlFR&file=ossimport-2.3.2.tar.gz b) 解压 ossimport;tar -zxvf ossimport-2.3.2.tar.gz c) 修改 worker,job.cfg以及sys.properties文件。 d) 注意worker中 master的ip写在第一行 e) 详细安装部署请参考:https://help.aliyun.com/document_detail/56990.html?spm=a2c4g.11186623.6.1109.d6a1pD 3.2Step2:安装ossimport 1.安装示例:安装示例 安装说明:安装过程中有可能提示任务无法执行,那是因为默认ubuntu没有安装java,请手工安装default-jre;Job.cfg文件配置:源与目的endpoint 均请填写内网二级域名(注意,不要写外网域名!!!!) 3.3Step3: 在master节点上运行 1. 在master运行: bash console.sh deploy 2. 提交任务: bash console.sh submit 3. 启动服务:Linux终端执行 bash console.start 4. 查看任务状态: bash console.sh stat
1. 服务端加密介绍 使用服务器端加密方式保护静态数据,即OSS将用户数据写入数据中心内的磁盘时,会在对象级别加密数据,并且在访问这些数据时自动解密。用户只需要验证请求是否拥有访问权限。当前OSS支持如下两种服务端加密方式(注意:您不能对同一对象同时应用两种不同类型的服务器端加密方式): 使用由OSS完全托管的服务端加密功能:数据加密密钥的生成和管理,由OSS负责,并采用高强度、多因素的安全措施进行保护。数据加密的算法采用使用行业标准的强加密算法AES-256(即256位高级加密标准)。 使用由KMS托管密钥的服务端加密功能:除了采用AES-256加密算法外,KMS负责保管用户主密钥CMK(对数据密钥进行加密的密钥),以及生成数据加密的密钥,通过信封加密机制,进一步防止未经授权的数据访问。其中,会涉及少量额外的KMS密钥API调用费用(参考:KMS计费标准)。暂时只支持中国大陆、香港、日本、新加坡区域,其余区域会尽快开放。 PS:如下重点介绍SSE-KMS加密方式: 2. 使用由KMS托管密钥的服务器端加密 KMS(Key Management Service)是阿里云提供的一款安全、易用的密钥管理系统。当用户上传object时,在请求中携带x-oss-server-side-encryption的HTTP Header,并指定其值为KMS。OSS支持使用默认的CMK加密对象,同时也支持使用用户指定的CMK 进行加密。 如上是SSE-KMS服务端加密的逻辑示意图。关于Customer Master Key的生成方式有多种,如下一一介绍: 使用OSS默认托管的KMS密钥:当用户上传object时,在请求中携带X-OSS-server-side-encrpytion并指定其值为KMS。OSS将使用默认托管的CMK加密每个对象,并且在下载时自定解密; 使用用户指定的CMK :当用户上传object时,在请求中指定X-oss-server-side-encrpytion-key-id为具体的CMK ID。OSS将使用指定的CMK(密钥材料来源于阿里云KMS)来加密每个对象。并且加密object的CMK ID记录到对象的元数据中,因此具有解密权限的用户下载对象时自动进行解密。 使用用户BYOK材料进行加密:目前阿里云KMS服务支持导入用户自己的BYOK密钥材料。如下图所示,用户创建1个不带密钥材料的CMK,并按照提示导入外部密钥材料。当用户上传object时,在请求中指定X-oss-server-side-encrpytion-key-id为使用外部密钥材料的CMK ID。 【补充说明】: 用户需要实现开通KMS服务; 使用“服务端加密-KMS托管主密钥”加解密对象时,会产生一定的KMS请求调用费用; 用于加密数据的数据密钥也会被加密,并且作为Object的元数据信息一并存储; KMS托管密钥的服务器端加密方式仅加密对象数据,不会加密任何对象的元数据; 1.目前以下操作,支持在请求中携带这些x-oss-server-side-encryption Header头: Put Object: 简单上传 Copy Object: 复制Object Initiate Multipart Upload: 2.通过服务器端加密存储的object时,以下API请求中OSS会返回x-oss-server-side-encryption头: Put Object Copy Object Initiate Multipart Upload Upload Part Complete Multipart Upload Get Object Head Object 3.配置示例: 3.1配置前提 演示region:香港站 演示bucket :test-hongkong-2025 演示工具:ossutil 3.2演示说明 【step1】:上传1个明文对象至OSS我们当前使用香港region进行演示说明。因此,我们将1个对象上传至香港region的bucket(bucket名:test-hongkong-2025) D:\5-AK账号\ossutil64>ossutil64.exe stat oss://test-hongkong-2025/01.txt ACL : default Accept-Ranges : bytes Content-Length : 62 Content-Md5 : k2GA4LeqHvVpQvBfnleNOg== Content-Type : text/plain Etag : 936180E0B7AA1EF56942F05F9E578D3A Last-Modified : 2018-10-24 20:41:54 +0800 CST Owner : 1416614965936597 X-Oss-Hash-Crc64ecma : 9888192182077127097 X-Oss-Object-Type : Normal X-Oss-Storage-Class : Standard 1.257000(s) elapsed 如上所示,我们上传了1个明文文件; 2.【step2】:在香港region创建KMS密钥由于KMS加密服务不支持跨region操作。因此,我们在香港region创建1个CMK,并且导入外部密钥材料。如下所示: 3.【step3】:使用指定的CMK ID加密上传对象为了简化演示过程,我们通过python将【step1】中上传的明文文件01.txt的加密属性修改为使用指定的CMK ID进行加密; #PYTHON 脚本如下 # -*- coding: utf-8 -*- import oss2 # 阿里云主账号AccessKey拥有所有API的访问权限,风险很高。强烈建议您创建并使用RAM账号进行API访问或日常运维,请登录 https://ram.console.aliyun.com 创建RAM账号。 auth = oss2.Auth('<yourAccessKeyId>', '<yourAccessKeySecret> ') # Endpoint以杭州为例,其它Region请按实际情况填写。 bucket = oss2.Bucket(auth, 'http://oss-cn-hongkong.aliyuncs.com', 'test-hongkong-2025') bucket.update_object_meta('01.txt',{'x-oss-server-side-encryption':'KMS','x-oss-server-side-encryption-key-id': '33701a45-6723-4a04-a367-68c060382652'}) 4.【step4】:查看使用指定CMK ID 加密对象的元数据信息如下,我们使用ossutil工具查看: D:\5-AK账号\ossutil64>ossutil64.exe stat oss://test-hongkong-2025/01.txt ACL : default Accept-Ranges : bytes Content-Length : 62 Content-Md5 : k2GA4LeqHvVpQvBfnleNOg== Content-Type : text/plain Etag : 936180E0B7AA1EF56942F05F9E578D3A Last-Modified : 2018-10-24 20:46:39 +0800 CST Owner : 1416614965936597 X-Oss-Hash-Crc64ecma : 9888192182077127097 X-Oss-Object-Type : Normal X-Oss-Server-Side-Encryption: KMS X-Oss-Server-Side-Encryption-Key-Id: 33701a45-6723-4a04-a367-68c060382652 X-Oss-Storage-Class : Standard 1.411000(s) elapsed
近日,阿里云在杭州云栖大会发布了OSS“同城区域冗余”存储产品。可满足企业级客户对于”发生机房级灾难事件时数据不丢失,业务不中断“的需求。相比于建设线下同城容灾机房,OSS“同城区域冗余”存储,可以极大的降低企业的建设成本。结合此前OSS发布了“跨区域复制”能力,如今阿里云OSS能够提供同机房、同城、跨地域三级完整的容灾服务能力。由于受限于IT能力、成本等因素,绝大多数企业级客户的关键业务数据并不具备同城容灾能力。机房的断网、断电、设备损坏等事件都有可能造成业务的中断,甚至是数据的丢失。因此,如何构建安全、可靠、弹性的灾备系统,成为了国内众多企业级客户最迫切的需求。今天,阿里云OSS发布了“同城区域冗余”存储产品。它能够将用户上传的数据,分散存放在同一个地域(Region)的三个不同可用区内。即使某个可用区整体毁坏时,仍然能够保证用户的业务数据能够正常使用。 此次发布的OSS“同城区域冗余”存储产品,具有如下3个特点: 提供机房级容灾能力:OSS“同城区域冗余”存储产品能够提供99.9999999999%的数据可靠性。当服务终端或者灾难事件导致某个机房不可用时,仍然能够确保继续提供强一致性的服务能力,整个故障切换过程用户无感知、业务不中断、数据不丢失。可满足关键业务系统对于RPO=0、RTO=0的强需求; 更高的SLA可用性指标:OSS“同城区域冗余”存储能够提供99.95%的可用性SLA指标,相比于单AZ标准存储类型,SLA可用性指标5倍提升。 一键开通:基于OSS“同城区域冗余”,能够非常方便的构建云上同城容灾服务能力。用户只需要在创建Bucket时,开启“同城区域冗余”存储属性即可。OSS采用多副本机制自动将用户的数据分散存放在同城相距数十公里的3个不同的可用区内。 目前OSS“同城区域冗余”存储已经在中国站的北京、上海、杭州、深圳Reigon上线发布。后续会面向更多区域开放。阿里云OSS再次改变了容灾系统的建设模式以及用户使用习惯。借助于创云计算的普惠能力,让更多的企业基于阿里云OSS构建“弹性、稳定、安全”的云上同城容灾业务系统。 【开通介绍】:[同城区域冗余存储]:[https://help.aliyun.com/document_detail/90589.html?spm=a2c4g.11186623.6.577.6d19b81edx4equ]
概述 OSS现在已经支持WORM特性。允许用户以不可擦除、不可重写的方式存储和使用OSS上的数据。这非常适合于金融、保险、在线协作等领域。第三方软件提供商和合作伙伴可以基于OSS的WORM特性提供云上数据合规存储。为了最大限度的保持数据的灵活性,OSS的WORM策略适合于所有的存储类型(包括标准存储类型、低频存储类型以及归档存储类型),现在您可以在开启WORM保护的Bucket上运用lifecycle策略进行存储类型转换以降低存储费用。 OSS的WORM特性具有如下特点: 提供基于时间的保留策略:用户可以创建WORM策略,当策略生效后。该Bucket内的文件得到保护,任何人都不能针对文件实施修改和删除操作; 支持所有的存储类型:WORM策略支持所有的存储类型,包括标准存储、低频存储、归档存储。用户可以将数据存储在最具成本效益的存储类型的同时,保持数据的合规性; 支持生命周期策略:针对开启了WORM策略的Bucket,允许设置生命周期策略,以自动进行存储类型转换。另外针对已经超过保护期的数据,可通过生命周期策略自动进行删除; WORM特性免费对外开放:用户可以在支付OSS的基本费用的基础之上,免费使用WORM特性; 工作原理 2.1基于时间的WORM策略: 在Bucket上应用基于时间的WORM策略,那么该Bucket上对象在有效保护周期内均不能被修改和删除。支持针对已存在内容的Bucket设置基于时间的WORM策略,对于已存在的对象的保护周期,则从文件最后一次修改的时刻进行计算。例如,2017年6月1日创建了名为testbucket的bucket,并上传了file1.txt文件,在2018年6月1日创建了基于时间的WORM策略(策略内容:有效保护周期5年),那么该bucket内file1.txt文件剩余有效保护周期是4年(从2018年6月1日~2022年5月31日)。对于该bucket内新上传的文件,文件的保护周期是5年(从2018年6月1日~2023年5月31日)。 此外,即使基于时间的WORM策略提交锁定后,Bucket所有者&授权用户依然可以延长保护周期,但是不允许删除和缩短保护周期; 基于时间的WORM策略,保护周期支持:1天到70年; 基于时间的WORM策略,只能添加1条; 2.2.WORM策略生效规则: 启动WORM策略24小时内:当WORM策略创建后,该策略处于待提交状态(InProgress)。但是InProgress状态只有24小时的有效期。在有效期内,此策略对应的资源(也就是bucket中内容)处于保护状态。在这24小时内,用户可以手工提交锁定该策略。一旦该策略被锁定(Locked),则后续再也无法修改和删除该策略(但是可以延长策略保护周期,不允许缩短保护周期) 启动WORM策略24小时后:若超过24小时,未提交锁定该策略。则24小时后该策略自动失效; 2.3WORM策略删除规则如下: WORM策略是Bucket的一种Metadata属性。当Bucket删除时,该Bucket对应的WORM策略以及访问策略也会被删除。因此当Bucket为空时,Bucket的所有者可以删除该Bucket,从而间接删除该Bucket的WORM策略。 启动WORM策略24小时内,若该WORM策略未提交锁定,则Bucket所有者&授权用户可以修改or删除该策略。 3.控制台设置 新建Bucket或者选择现有的bucket,以便存储需要保持不可删除、不可覆盖的对象; 在Bucket的“基础设置”中,选择“WORM策略。弹出如下对话框: 输入保留时间(以天为单位,至少是1天,最长是25550天); Tips:策略的初始状态为“未锁定”。 您有24小时的时间进行测试体验,若24小时内未手工提交策略锁定,则24小时后策略自动失效; 锁定策略,选中inprogress状态的策略,点击“锁定”; Tips:选择“锁定策略”,此时策略状态会显示为“已锁定”。 锁定策略后无法将其删除,只允许延长保留时间间隔。
1.引子:如何授权子账号在控制台针对指定的Bucket设置图片样式呢? 【使用场景】:某企业内部有众多Bucket,并且不同的Bucket分别指定了Bucket的管理员。目前Bucket A的管理员期望能够针对Bucket A中的图片通过设置图片样式的方式进行通过管理。目前可以通过授权子账号“AliyunOSSFullAccess”权限的方式在控制台进行图片样式设置。但是赋予子账号“AliyunOSSFullAccess”后,子账号的操作权限过大。该账号能够操作管理所有的Bucket。在企业的实际使用过程中,每个Bucket都是由明确的使用用途,基本不可能授予每个子账号管理所有Bucket的权限。 因此,我们考虑是不是可以通过RAM Policy的方式针对指定的子账号授予指定Bucket的操作管理权限。从而达到如上的预期? 2.配置操作 2.1准备工作: 创建1个子账号;(示例中子账号tmp-user) 创建1个Bucket;(示例中Bucket名称test-beijing-2019) 创建RAM Policy;(示例中的RAM Policy名称 BucketStylePolicy) 2.2 创建RAM Policy: 由于是在请求图片时带上了图片样式处理操作,例如“http://image-demo.oss-cn-hangzhou.aliyuncs.com/example.jpg?x-oss-process=image/resize,h_100”。 因此RAM Policy需要包含2部分的授权: Get Object以及List Objects相关授权; 图片样式处理相关授权;其中图片样式相关API操作如下.PS:详细图片样式相关API操作:图片样式API接口 Put Style //创建图片样式 List Style //获取某个Bucket下所有图片样式信息 Get Style //获取某个样式(Style)的属性信息,包括样式名称、内容,以及创建和最后修改时间 Delete Style //删除某个图片样式 如下是授予子账号创建、修改、删除图片样式的相关RAM Policy授权: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:GetObject", "oss:PutObject", "oss:GetObjectAcl", "oss:PutObjectAcl", "oss:ListObjects", "oss:GetBucketAcl", "oss:Putstyle", "oss:Liststyle", "oss:Getstyle", "oss:Deletestyle" ], "Resource": [ "acs:oss:*:*:test-beijing-2019", "acs:oss:*:*:test-beijing-2019/*" ], "Condition": {} } ] } 2.3子账号登录控制台进行验证: 1.使用子账号(tmp-user)登录控制台,并且创建style: 2.在请求中使用图片样式,例如:https://test-beijing-2019.oss-cn-beijing.aliyuncs.com/0012.jpg?x-oss-process=style/STYLE2;
一、如何在控制台上查看Bucket的运维监控信息? 方式一:通过根账号登录OSS控制台进行访问。 通过阿里云根账号登录OSS控制台能够查看到所有Bucket的运维监控信息。但是在企业的实际运行过程中,直接使用根账号进行操作,安全风险极大。并且该方式查看到的是所有Bucket的信息,无法精确到指定的Bucket信息; 方式二:通过RAM 授权子账号在控制台查看: 由于查看OSS的监控信息,需要获取云监控相关的授权。我们采用RAM提供的默认授权。给针对的子账号授予如下RAM默认授权: “只读访问云监控的权限”; AliyunOSSFullAccess; 使用该方式授权后,可以允许子账号登录控制台查看Bucket的授权信息,而且避免了使用根账号授权过大的风险。但是该授权方式也存在漏洞,就是该子账号能够查看所有Bucket的监控信息。 那么如何授权子账号在控制台上查看指定Bucket的监控信息(包括概览、基础数据、热点统计、API统计、文件访问统计)? 由于当前云监控(CloudMonitor)不支持细颗粒度资源描述,只支持*通配。因此我们要针对RAM提供的默认“只读访问云监控的授权”进行改造。想起RAM policy配置操作如下: 二、RAM Policy配置操作 2.1前提准备 创建1个子账号; 创建对应的Bucket; 2.2通过RAM policy授权步骤如下: 创建1个查看Bucket概要信息的RAM Policy:授权子账号能够查看Bucket的概要信息; 创建1个云监控的RAM Policy:使之能够查看某个指定的Bucket监控信息; 2.3创建查看Bucket 的RAM Policy: 查看Bucket的概要信息以及监控信息需要获取“GetBucketInfo”的授权。此外登录控制台访问额外还需要'GetBucketACL'的授权。因此,我们创建1个RAM Policy(例如,名称为 GetBucketInfoPolicy)。如下示例中Bucket名称是“test-beijing-2019”: { "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:GetBucketAcl", "oss:GetBucketinfo" ], "Resource": [ "acs:oss:*:*:test-beijing-2019" ], "Condition": {} } ] } 2.4创建云监控的RAM Policy: 在控制台查看Bucket的监控信息(包括概览、基础数据、热点统计、API统计、文件访问统计),需要云监控相关授权。但是由于云监控需要ListBuckets权限,该授权能够允许查看所有的Bucket信息。因此,我们针对RAM 提供的默认云监控Policy进行改造。相关RAM Policy 如下: { "Version": "1", "Statement": [ { "Action": [ "cms:Get*", "cms:List*", "cms:Query*", "cms:BatchQuery*" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "ecs:DescribeInstances", "rds:DescribeDBInstances", "slb:DescribeLoadBalancer*", "vpc:DescribeEipAddresses", "vpc:DescribeRouterInterfaces", "vpc:DescribeGlobalAccelerationInstances", "vpc:DescribeVpnGateways", "vpc:DescribeNatGateways", "vpc:DescribeBandwidthPackages", "vpc:DescribeCommonBandwidthPackages", "log:ListProject", "cdn:DescribeUserDomains", "mns:ListQueue", "mns:ListTopic", "ess:DescribeScalingGroups", "ocs:DescribeInstances", "kvstore:DescribeInstances", "hbase:DescribeClusterList", "hitsdb:DescribeHiTSDBInstanceList", "dds:DescribeDBInstances", "petadata:DescribeInstances", "petadata:DescribeDatabases", "gpdb:DescribeDBInstances", "emr:ListClusters", "opensearch:ListApps", "elasticsearch:ListInstance" ], "Resource": "*", "Effect": "Allow" } ] } 如上RAM Policy,相比于RAM 提供的默认Policy: “AliyunCloudMonitorReadOnlyAccess”。我们取消了"oss:ListBuckets"授权操作。PS:取消"oss:ListBuckets"的目的就是禁止云监控默认列出所有Bucket的监控信息。 2.5控制台查看效果 我们将如上2个RAM Policy授权给新建的子账号; 使用子账号登录控制台后,由于没有ListBuckets权限,所以控制台不会展示Bucket列表信息。因此需要我们在控制台的左上角“我的访问路径”中手工添加对应的Bucket名称。 添加Bucket名称后,刷新控制台后,我们就能够在控制台查看到指定Bucket的监控信息了; 图1:授权子账号登录控制台查看指定Bucket监控信息 【补充说明】:由于是修改了默认的云监控授权,因此子账号无法在“云监控”页面查看指定bucket的监控信息。
如何让1个外部用户访问某个OSS资源? 某大型企业A使用OSS作为后端资源存储平台,当该企业期望将内部数据分享给下游合作伙伴B,那么基于阿里云OSS平台,有多少种方式呢? 方式1:基于Bucket 以及Object ACL: Bucket 所有者将需要分享的文件ACL设置为“Public”模式,那么外部用户可以直接访问该文件的URL,而不需要通过身份认证以及鉴权操作。 图1:配置对象的ACL 方式2:使用签名URL方式: Bucket所有者设置待分享文件的签名url信息,外部用户接收到该url后,在指定的时间内访问该文件; 图2:设置对象的签名URL 方式3:使用RAM policy方式: 若下游合作伙伴也是阿里云用户,那么可以基于sts(Security Token Service)方式进行授权访问,企业A管理员创建角色Role A,并且指定企业B账号进行扮演该角色Role A,通知企业A管理员设置RAM Policy(如下),并且将该RAM Policy赋予给Role A。企业B管理员可以使用根账号或者子账号扮演角色RoleA,然后使用Assumerole返回的临时token以及secret ID信息在指定的时间段内访问企业A的资源。 "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:GetObject", "oss:ListObjects", "oss:GetObjectAcl" ], "Resource": [ "acs:oss:*:*:test-resource" ], "Condition": {} } ] } 方式4:使用Bucket Policy: 若下游合作伙伴也是阿里云用户,那么Bucket Owner可以直接基于该资源配置Bucket Policy策略,在策略中指定允许访问该资源的对象,以及允许的访问操作权限。 图3:设置Bucket Policy Bucket policy 优劣势 针对用户访问资源的授权,我们列出了常见的4种不同的配置方式,那么这4种配置方式各有设么优缺点呢? 图5:4种配置方式的优劣势 Bucket Policy是什么? 默认情况下,所有阿里云OSS资源都是私有的,包括Bucket,对象。只有资源拥有者才能访问这些资源,另外资源的拥有者可以通过配置访问策略授权他人访问权限。 阿里云OSS提供的访问策略大致可分为基于资源的策略以及基于用户的策略两类。附加到资源(Bucket和对象)的访问策略称之为基于资源的策略。例如,Bucket Policy以及访问控制列表(ACL)就是基于资源的策略,另外也可以将访问策略附加到根账号下的子用户,这种策略称之为用户策略,例如:RAM Policy。 3.1 bucket policy简介 Bucket 的所有者可以通过设置Bucket Policy设置针对bucket以及bucket内对象的访问权限。 Bucket policy可以基于各种参数,例如“被授权账号/子用户,访问条件”等。附加到某个bucket的权限适用于该bucket内所有对象。设置Bucket Policy策略后,后续对该bucket的访问请求都将会受到Bucket Policy的限制。 3.2Bucket Policy配置过程 当前Bucket Policy只能在控制台进行配置图形化配置操作。选中某个对象,点击“授权”,或者点击“操作授权”,弹出如下配置对话框: 图6:添加“操作授权” 各个字段的含义如下表1所示: 字段 值 描述 授权资源 1. 若选中某个对象,直接点击“授权”,则此处会自动填充对应资源的路径;2. 若点击“操作授权”,则需要输入对应的资源路径。 1.若资源为bucket时,“授权操作”作用于bucket以及bucket内所有子对象;2. 若资源为对象或者目录,“授权操作”作用于该对象或者该目录下所有的子对象; 授权用户 输入格式:授权给账号:输入对应账号ID; 授权给子用户:输入对应子用户的ID Bucket Policy支持跨账号授权;若授权给匿名用户,则勾选“所有用户”; 授权操作 为了简化授权过程,oss针对常见的授权场景进行了简化操作,目前只提供“只读”、“读写”以及“完全控制”、“拒绝访问”操作。 1.“只读”2.“读写”;3. “完全控制” 4."拒绝访问" 条件 IP等于、IP不等于 当输入多个IP地址或者IP地址段时,用英文逗号分隔; 3.3bucket Policy配置示例 相比于RAM policy,Bucket Policy支持在控制台直接进行图形化配置操作,并且Bucket 所有者直接可以进行访问授权。Bucket Policy常见的应用场景有如下几种: 向其他账号的子用户授权访问 向匿名用户授权于带特定IP条件限制的访问权限 1.向其他账号下的子用户授权 以下策略显示了bucket 所有者向其他账号下的子账号(UID:237683216696367672)授予只读权限的配置过程。 图7:向其他账号下的子账号授权 2.向匿名用户授权于带特定IP条件限制的访问权限 以下示例允许向匿名用户授予待IP限制的访问策略。例如,企业内部的机密文档,只允许在企业内部访问,不允许在其他区域访问。由于企业内部人员较多,针对每个人配合RAM policy,手工操作工作量非常大。因此基于bucket policy设置带IP限制的访问策略,是非常有效的。 图8:向匿名用户授权于带特定IP条件限制的访问权限 Tips:授予对bucket的匿名用户访问操作时需谨慎使用。若授予匿名访问权限不带条件限制,那么意味着世界上任何人都可以访问该资源.
2020年09月
2019年08月
2019年07月
2019年06月