[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-884":3,"consumer-news-interaction-884":40,"consumer-news-related-884":43},{"detail":4,"item":35},{"card":5,"schemaVersion":22,"fields":23,"content":29},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":19,"tags":20,"resolved":21},"NEWS_ARTICLE:884","news","NEWS_ARTICLE",884,"资讯","OSS 文件上传的几个风险点和解决方案","博客园","〇、前言 OSS 作为海量数据的承载平台，一旦配置不当，可能引发敏感数据泄露、恶意文件上传、巨额流量盗刷甚至数据被勒索加密等严重后果。 了解这些风险并非杞人忧天，而是帮助开发者和运维人员在使用 OSS 时建立正确的安全思维——从凭证管理、权限控制、访问策略到上传校验，每一个环节都可能在疏忽中成为攻击","","\u002Fnews\u002F884",[17,18],"2026","数据与架构",{},[18],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":24,"categoryName":18,"summary":13,"description":13,"publishTime":25,"updateTime":26,"sourceUrl":27,"language":28},"橙子家","2026-08-31T23:02","2026-09-02T20:37:52","https:\u002F\u002Fwww.cnblogs.com\u002Fhnzhengfy\u002Fp\u002F22716119\u002Foss","中文",{"format":30,"policy":31,"normalized":21,"html":32,"text":33,"wordCount":34,"hasBody":21},"HTML","NEWS_CONTENT_V1","\u003Ch2>〇、前言\u003C\u002Fh2>\n\u003Cp>\u003Cspan>\u003Cstrong>OSS 作为海量数据的承载平台，一旦配置不当，可能引发敏感数据泄露、恶意文件上传、巨额流量盗刷甚至数据被勒索加密等严重后果。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>了解这些风险并非杞人忧天，而是帮助开发者和运维人员在使用 OSS 时建立正确的安全思维——从凭证管理、权限控制、访问策略到上传校验，每一个环节都可能在疏忽中成为攻击入口。\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>只有提前识别风险、主动防御，才能确保数据在享受云存储便利的同时，始终处于安全可控的状态。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>那么本文就来简单介绍下什么是 OSS，以及如何规避常见的风险，供参考。\u003C\u002Fp>\n\u003Ch2>一、关于：对象存储服务（Object Storage Service）\u003C\u002Fh2>\n\u003Ch3>1.1 简介\u003C\u002Fh3>\n\u003Cp>对象存储服务（简称 OSS 或 OBS 等）是云计算时代专为\u003Cspan>\u003Cstrong>海量非结构化数据\u003C\u002Fstrong>\u003C\u002Fspan>设计的分布式存储解决方案。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1）为什么需要对象存储？\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>在互联网时代，产生了海量的非结构化数据（如：图片、视频、日志、备份文件等）。传统的存储方式在面对这些数据时暴露出明显的瓶颈：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>块存储（如：硬盘）：\u003C\u002Fstrong>扩展性差，跨节点扩展困难，且不支持原生共享，通常用于数据库或虚拟化平台。\u003Cbr>\u003Cstrong>文件存储（如：NAS）：\u003C\u002Fstrong>虽然支持共享，但采用层级目录结构，当目录内文件极多时性能会严重衰减，扩展性受限。\u003C\u002Fp>\n\u003Cp>对象存储正是为了克服上述缺点而诞生的。\u003Cspan>\u003Cstrong>它摒弃了传统的层级目录结构，采用扁平化命名空间，将数据与元数据封装在一起，通过分布式架构实现了近乎无限的横向扩展。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）核心概念解析\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>要使用对象存储，必须掌握以下三个最核心的概念：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>Bucket（存储空间\u002F桶）\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>它是\u003Cstrong>对象存储的顶层容器\u003C\u002Fstrong>，类似于传统文件系统中的“根目录”，但内部是扁平的，\u003Cspan>\u003Cstrong>没有真正的子目录\u003C\u002Fstrong>\u003C\u002Fspan>。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>每个 Bucket 都有全局唯一的名称，且创建后所属区域不可更改。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>Object（对象）\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这是存储的基本数据单元。一个对象由三部分组成：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Key（键名）：\u003C\u002Fstrong>对象的唯一标识符，类似文件路径（如：images\u002F2025\u002Fphoto.jpg）。\u003Cbr>\u003Cstrong>Value（数据）：\u003C\u002Fstrong>实际的二进制数据内容（图片、视频、文本等），对象存储不关心其内部格式。\u003Cbr>\u003Cstrong>Metadata（元数据）：描述数据的属性。\u003C\u002Fstrong>包括系统自动生成的（如：文件大小、类型）和用户自定义的（如：作者、项目名），可用于业务分类和检索。\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>Endpoint（访问域名）与 AccessKey（访问密钥）\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Endpoint：对外服务的访问域名，不同地域的 Bucket 对应不同的 Endpoint。\u003Cbr>\n AccessKey：用于身份验证的密钥（包含 ID 和 Secret），确保只有授权用户才能访问数据。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3）对象存储 vs 文件存储 vs 块存储\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>这三种存储的核心区别在于数据的组织方式和访问接口。以下是它们的对比：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>维度\u003C\u002Fth>\n   \u003Cth>块存储\u003C\u002Fth>\n   \u003Cth>文件存储\u003C\u002Fth>\n   \u003Cth>\u003Cstrong>对象存储\u003C\u002Fstrong>\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>数据单位\u003C\u002Ftd>\n   \u003Ctd>固定大小的块（512B~4KB）\u003C\u002Ftd>\n   \u003Ctd>文件 + 目录层级\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>对象（数据 + 元数据 + Key）\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>访问接口\u003C\u002Ftd>\n   \u003Ctd>SCSI \u002F iSCSI \u002F FC\u003C\u002Ftd>\n   \u003Ctd>POSIX（open\u002Fread\u002Fwrite）\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>RESTful API \u002F SDK\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>扩展性\u003C\u002Ftd>\n   \u003Ctd>垂直扩展为主\u003C\u002Ftd>\n   \u003Ctd>中等，受索引性能限制\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>【无限横向扩展】\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>共享性\u003C\u002Ftd>\n   \u003Ctd>不支持原生共享\u003C\u002Ftd>\n   \u003Ctd>支持网络共享\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>【跨平台跨地域共享】\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>随机写\u003C\u002Ftd>\n   \u003Ctd>【支持】\u003C\u002Ftd>\n   \u003Ctd>【支持】\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>【不支持】（只能整体覆盖）\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>典型用户\u003C\u002Ftd>\n   \u003Ctd>数据库、虚拟化平台\u003C\u002Ftd>\n   \u003Ctd>办公文档、视频编辑\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>云原生应用、CDN、数据湖\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>一句话选型指南：\u003Cspan>\u003Cstrong>追求低延迟、高 IOPS 选块存储；需多用户共享、目录管理选文件存储；海量数据、云原生、跨地域分发选对象存储\u003C\u002Fstrong>\u003C\u002Fspan>。\u003C\u002Fp>\n\n\u003Ch3>1.2 对象存储的核心优势与应用场景\u003C\u002Fh3>\n\u003Cp>OSS 的三个核心优势。\u003C\u002Fp>\n\u003Cp>1）\u003Cstrong>高可靠性与持久性：\u003C\u002Fstrong>通过多重冗余架构，主流云厂商的对象存储数据持久性可达 99.9999999999%（12 个 9），数据几乎不会丢失。\u003Cbr>\n 2）\u003Cstrong>低成本与弹性：\u003C\u002Fstrong>无需前期硬件投资，按需付费。支持生命周期管理，自动将冷数据转为低成本存储类型。\u003Cbr>\n 3）\u003Cstrong>强一致性：\u003C\u002Fstrong>现代对象存储（如：AWS S3、阿里云 OSS）已支持强一致性，写入成功后立即可读，不存在中间状态。\u003C\u002Fp>\n\u003Cp>典型应用场景：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>静态资源托管与分发：\u003C\u002Fstrong>网站\u002FApp 的图片、音视频、CSS\u002FJS 文件存放在对象存储，结合 CDN 实现全球加速，大幅减轻源站服务器压力。\u003Cbr>\u003Cstrong>海量数据备份与归档：\u003C\u002Fstrong>数据库备份、系统日志、医疗影像等长期保存的数据，可利用归档存储类型大幅降低成本1。\u003Cbr>\u003Cstrong>大数据与 AI 数据湖：\u003C\u002Fstrong>作为底层存储，存放 AI 训练数据、模型文件和大数据分析结果，支持 PB 级数据处理和高带宽下载。\u003Cbr>\u003Cstrong>内容分享与网盘应用：\u003C\u002Fstrong>提供安全的文件直传、防盗链保护以及在线预览等功能，支撑各类 SaaS 应用。\u003C\u002Fp>\n\u003Cp>总而言之，对象存储已经成为现代 IT 架构中不可或缺的基础设施。如果正在开发网站、App 等应用中，\u003Cspan>\u003Cstrong>面临海量非结构化数据的存储与管理难题，将静态资源从传统服务器中剥离并迁移至对象存储，是优化架构、降低成本的最佳实践\u003C\u002Fstrong>\u003C\u002Fspan>。\u003C\u002Fp>\n\u003Ch2>二、规避 OSS 安全风险的具体做法\u003C\u002Fh2>\n\u003Ch3>2.1 凭证管理：从源头杜绝 AccessKey 泄露\u003C\u002Fh3>\n\u003Cp>这是\u003Cspan>\u003Cstrong>日常开发中最高频、也最容易出问题的环节\u003C\u002Fstrong>\u003C\u002Fspan>。以下是\u003Cspan>\u003Cstrong>绝对禁止\u003C\u002Fstrong>\u003C\u002Fspan>的做法。\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>在代码中\u003Cspan>硬编码\u003C\u002Fspan> AccessKey（accessKeyId = \"LTAI5t...\"）。\u003C\u002Fstrong>\u003C\u002Fli>\n \u003Cli>\u003Cstrong>在前端\u002FAPP\u002F小程序代码中\u003Cspan>嵌入任何形式的 AK\u003C\u002Fspan>。\u003C\u002Fstrong>\u003C\u002Fli>\n \u003Cli>\u003Cspan>\u003Cstrong>将包含 AK 的配置文件提交到 Git 仓库。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>不同的场景需要不同的策略，下面简单例举几个。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1）服务端应用（Java\u002FPython\u002FNode.js 等）\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>通过环境变量读取凭证，代码中只引用变量名。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>部署时通过 .env 文件、配置中心（如：Nacos、Apollo）或云厂商的密钥管理服务（KMS）注入环境变量，而非写死在代码里。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）前端\u002F移动端应用\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>前端绝不能持有长期凭证。正确做法是通过 STS 临时凭证实现。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>前端向你的业务服务器请求临时凭证。\u003C\u002Fli>\n \u003Cli>业务服务器调用 AssumeRole 接口，向 STS 服务申请一个有效期短（建议 15~60 分钟）的临时 Token。\u003C\u002Fli>\n \u003Cli>前端拿到临时 Token 后直传 OSS。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode>前端 APP ──请求临时凭证──▶ 业务服务器 ──AssumeRole──▶ STS 服务\n前端 APP ◀──返回临时Token── 业务服务器 ◀──返回STS Token── STS 服务\n前端 APP ──使用临时Token上传──▶ OSS\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>3）ECS\u002F容器环境\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>如果在阿里云 ECS、ECI 或 ACK 上运行，\u003Cspan>直接使用实例 RAM 角色，通过元数据服务自动获取临时凭证，完全无需管理 AK。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cpre>\u003Ccode># ECS 实例元数据服务自动获取 STS Token\ncurl http:\u002F\u002F100.100.100.200\u002Flatest\u002Fmeta-data\u002Fram\u002Fsecurity-credentials\u002FYourRoleName\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>4）工程化防护手段\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Git pre-commit hook：\u003C\u002Fstrong>使用 git-secrets、gitleaks 或 trufflehog 等工具，在代码提交前自动扫描是否包含 AK 特征（如阿里云 AK 以 LTAI 开头），命中则阻止提交。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>CI\u002FCD 流水线集成扫描：\u003C\u002Fstrong>在构建阶段加入密钥泄露检测，作为质量门禁的一部分。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>定期轮换：\u003C\u002Fstrong>制定 AK 轮换计划（建议 90 天），通过 KMS 凭据管家实现自动轮转。\u003C\u002Fp>\n\n\u003Ch3>2.2 权限控制：最小权限原则落地\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1）永远不用主账号 AK\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>主账号 AK 拥有所有云资源的完全控制权，一旦泄露后果不堪设想。\u003C\u002Fspan>务必创建 RAM 子账号，且每个应用\u002F服务使用独立的子账号。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）自定义策略精确授权\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>不要用 AliyunOSSFullAccess 这种全量策略（仅限测试环境快速验证），\u003Cspan>\u003Cstrong>生产环境应编写自定义策略，精确到具体 Bucket 和具体操作。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>{\n  \"Version\": \"1\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"oss:PutObject\",\n        \"oss:GetObject\"\n      ],\n      \"Resource\": [\n        \"acs:oss:*:*:my-app-bucket\u002Fuploads\u002F*\"\n      ]\n    }\n  ]\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>上述策略只允许向 my-app-bucket 的 uploads\u002F 目录上传和下载文件，无法列举其他 Bucket、无法删除文件、无法修改权限。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3）STS 临时凭证也要限制权限范围\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>签发 STS Token 时，通过 Policy 参数进一步收窄临时凭证的权限，例如只允许上传到特定目录。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>{\n  \"Version\": \"1\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"oss:PutObject\",\n      \"Resource\": \"acs:oss:*:*:my-app-bucket\u002Fuser-uploads\u002F${userId}\u002F*\"\n    }\n  ]\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch3>2.3 Bucket 配置：开发阶段就要定好安全基线\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1）创建 Bucket 时的检查清单\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>配置项\u003C\u002Fth>\n   \u003Cth>推荐值\u003C\u002Fth>\n   \u003Cth>说明\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>ACL\u003C\u002Ftd>\n   \u003Ctd>私有（private）\u003C\u002Ftd>\n   \u003Ctd>默认值，绝大多数场景不需要改\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>阻止公共访问\u003C\u002Ftd>\n   \u003Ctd>开启\u003C\u002Ftd>\n   \u003Ctd>默认已开启，防止误操作导致数据公开\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>版本控制\u003C\u002Ftd>\n   \u003Ctd>开启（重要数据）\u003C\u002Ftd>\n   \u003Ctd>误删\u002F误覆盖后可一键恢复\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>服务端加密\u003C\u002Ftd>\n   \u003Ctd>开启\u003C\u002Ftd>\n   \u003Ctd>数据落盘自动加密\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>HTTPS 强制\u003C\u002Ftd>\n   \u003Ctd>开启\u003C\u002Ftd>\n   \u003Ctd>拒绝 HTTP 明文传输\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>\u003Cstrong>2）开发环境 vs 生产环境 \u003Cspan>隔离\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>使用\u003Cspan>\u003Cstrong>不同的 Bucket 区分\u003C\u002Fstrong>\u003C\u002Fspan>开发、测试、生产环境。\u003C\u002Fli>\n \u003Cli>开发环境的 RAM 子账号不应有生产 Bucket 的任何权限。\u003C\u002Fli>\n \u003Cli>Bucket 命名建议包含环境标识：myapp-dev-assets、myapp-prod-assets。\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>2.4 数据传输与访问安全\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1）签名 URL 设置合理有效期\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>对外分享私有文件时，使用签名 URL 并\u003Cspan>\u003Cstrong>设置合理的过期时间\u003C\u002Fstrong>\u003C\u002Fspan>（建议不超过 3600 秒（1小时））。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）强制 HTTPS\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>在 Bucket 的 Bucket Policy 中添加规则，拒绝所有非 HTTPS 请求，防止数据在传输过程中被窃听。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3）配置 CORS 白名单\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>如果前端需要通过 JS 直接访问 OSS，务必在 CORS 配置中限定允许的 Origin 为你的业务域名，而不是设置为 *。\u003C\u002Fp>\n\n\u003Ch3>2.5 防盗链与流量控制\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1）Referer 防盗链\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>对于公共读的静态资源 Bucket，配置 Referer 白名单，仅允许自己的网站域名访问。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>白名单：https:\u002F\u002Fwww.yourdomain.com、https:\u002F\u002F*.yourdomain.com。\u003C\u002Fli>\n \u003Cli>勾选\"不允许空 Referer\"（防止直接在浏览器地址栏访问）。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>2）搭配 CDN 使用\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>将 OSS 作为 CDN 的源站，日常访问走 CDN 缓存，减少 OSS 直接外网流量，同时 CDN 层可叠加额外的鉴权和防护能力。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3）用量告警\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>在控制台\u003Cspan>设置存储量、外网流量、请求次数的告警阈值\u003C\u002Fspan>，当出现异常飙升时第一时间收到通知。\u003C\u002Fp>\n\n\u003Ch3>2.6 数据保护：开发阶段就要考虑\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1）版本控制\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>对存储重要业务数据的 Bucket 开启版本控制。上传同名文件时自动保留历史版本，误删后可一键恢复。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）生命周期规则要谨慎\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>配置生命周期规则时，务必确认前缀范围：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>backups\u002F — 只作用于 backups 目录。\u003C\u002Fli>\n \u003Cli>前缀为空 — 将作用于 Bucket 中所有文件，可能导致全部数据被自动删除或转储。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>3）跨区域复制\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>核心业务数据建议开启\u003Cstrong>\u003Cspan>跨区域复制\u003C\u002Fspan>\u003C\u002Fstrong>，虽然这样增加了成本，但是可以尽量确保在一个地域发生故障时数据仍可访问。\u003C\u002Fp>\n\n\u003Ch3>2.7 另外一个细节：上传文件的类型限定\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>当 OSS 允许上传任意类型文件且不做限制时，会存在诸多风险\u003C\u002Fstrong>，例如：\u003C\u002Fp>\n\u003Cp>1）上传恶意 HTML\u002FJS 文件（如：<script>alert(document.cookie)<\u002Fscript>），若通过同源域名直接访问，浏览器会执行其中的脚本，形成存储型 XSS。\u003Cbr>\n 2）上传 .exe、.apk、.sh 等可执行文件，借助受信任的 OSS 域名进行恶意软件分发，用户因信任域名而放松警惕。\u003Cbr>\n 3）上传 .svg、.xml 等文件，其中可嵌入脚本代码，同样触发 XSS。\u003Cbr>\n 4）利用 Flash\u002FPDF 等富媒体文件的漏洞，进行更复杂的攻击。\u003C\u002Fp>\n\u003Cp>核心问题在于：OSS 域名被视为“可信源”，一旦攻击者在该域名下植入恶意内容，浏览器的同源策略反而会“保护”这些恶意代码的执行。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>以下是一种多层解决方案。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>1）上传阶段——严格校验文件类型\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cspan>\u003Cstrong>白名单机制（最关键）。\u003C\u002Fstrong>\u003C\u002Fspan>只允许业务需要的文件类型通过，拒绝一切未明确允许的类型。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode>using System;\nusing System.Collections.Generic;\nusing System.IO;\n\u002F\u002F 允许的扩展名白名单\nprivate static readonly HashSet<string> AllowedExtensions = new(StringComparer.OrdinalIgnoreCase)\n{\n    \"jpg\", \"jpeg\", \"png\", \"gif\", \"pdf\", \"doc\", \"docx\", \"xlsx\", \"mp4\"\n};\npublic bool IsAllowed(string filename)\n{\n    \u002F\u002F Path.GetExtension 返回带 \".\" 的扩展名，如 \".jpg\"，需要去掉前导点\n    string ext = Path.GetExtension(filename).TrimStart('.').ToLower();\n    return AllowedExtensions.Contains(ext);\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cul>\n \u003Cli>\u003Cstrong>Content-Type 校验。\u003C\u002Fstrong>不能仅依赖客户端传入的 Content-Type（可伪造），需结合文件扩展名和服务端检测。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>文件头（Magic Number）校验。\u003C\u002Fstrong>读取文件的前几个字节，验证其是否与声明的类型一致，防止\"改扩展名\"绕过。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode>byte[] header = ReadFirstBytes(file, 4);\nif (!header.SequenceEqual(new byte[] { 0xFF, 0xD8, 0xFF }))\n{\n    throw new SecurityException(\"文件内容与声明类型不符\");\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cul>\n \u003Cli>\u003Cstrong>文件大小限制。\u003C\u002Fstrong>设置合理的上传上限，防止大文件耗尽存储资源或造成 DoS。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cspan>\u003Cstrong>2）存储与访问阶段——隔离与降权\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cspan>\u003Cstrong>存储 Bucket 与访问域名分离（极其重要）\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>业务域名（如：www.example.com）：用于提供页面，携带 Cookie、登录态。\u003Cbr>\n OSS 访问域名（如：files.oss-cn-xxx.aliyuncs.com 或独立的 cdn.example-files.com）：专门用于访问上传的文件。\u003C\u002Fp>\n\u003Cp>两者必须使用不同的域名，确保即使 OSS 上的文件包含恶意脚本，也无法读取业务域名下的 Cookie 和 Session。\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>禁止 OSS 域名直接渲染可执行内容\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>对用户上传的文件，访问时通过响应头强制浏览器以下载方式处理，而非直接渲染：\u003Ccode>Content-Disposition: attachment; filename=\"xxx.pdf\"\u003C\u002Fcode>。\u003C\u002Fp>\n\u003Cp>或者对图片等需要在线展示的类型，使用图片处理服务（如 OSS 的图片缩放参数）返回处理后的图片，而非原始文件。\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>设置安全的 Cache-Control 和 CSP\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>在 OSS 或 CDN 层为文件设置安全响应头：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; img-src data: X-Content-Type-Options: nosniff\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cul>\n \u003Cli>\u003Cspan>\u003Cstrong>文件重命名\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>上传后使用随机 UUID 重命名文件，避免攻击者通过文件名预测路径或利用特殊文件名（如：index.html）覆盖关键文件。\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>3）\u003Cspan>运行时防护\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>定期扫描与清理。\u003C\u002Fstrong>对已存储文件进行定期安全扫描，检测是否存在可疑内容。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>访问日志与异常监控。\u003C\u002Fstrong>监控 OSS 访问日志，对异常流量（如大量下载、异常 User-Agent）进行告警。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>三、一个简单的检查清单\u003C\u002Fh2>\n\u003Cp>如下检查项，可以纳入团队的 Code Review 和上线流程。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>□ 代码中是否存在硬编码的 AccessKey？（用 gitleaks 扫描）\n□ 前端\u002F移动端是否使用了 STS 临时凭证而非长期 AK？\n□ 新建 Bucket 的 ACL 是否为私有？\n□ RAM 策略是否遵循最小权限原则？\n□ 签名 URL 的有效期是否合理（≤ 3600 秒）？\n□ 是否配置了 Referer 防盗链？\n□ 是否开启了用量告警？\n□ 重要 Bucket 是否开启了版本控制？\n□ 生命周期规则的前缀范围是否正确？\n□ 删除 Bucket 前是否已清除 CNAME 域名解析？\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>四、小小的总结\u003C\u002Fh2>\n\u003Cp>本文从对象存储的基础概念出发，系统梳理了 OSS 在实际使用中面临的安全风险及对应的规避策略，核心要点可归纳为以下三个层面：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1. 认知层：理解对象存储的本质与边界\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>对象存储以扁平化命名空间和 RESTful API 为核心，天然适合海量非结构化数据的存储与分发，但在随机写、事务一致性等方面存在固有局限。\u003Cstrong>选型时应根据业务特征在块存储、文件存储与对象存储之间做出合理取舍，避免\"用错工具\"带来的架构隐患。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2. 安全层：将安全左移，嵌入开发全流程\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>OSS 安全风险的根源大多不是产品缺陷，而是配置疏忽与开发习惯。贯穿全文的安全实践可浓缩为以下关键原则：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>安全维度\u003C\u002Fth>\n   \u003Cth>核心原则\u003C\u002Fth>\n   \u003Cth>关键动作\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>凭证安全\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>凭证不落代码\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>环境变量\u002FKMS 管理、STS 临时凭证、Git Hook 扫描\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>权限控制\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>最小权限原则\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>RAM 子账号、自定义策略精确授权、STS 进一步收窄\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>资源基线\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>创建即安全\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>私有 ACL、阻止公共访问、版本控制、服务端加密、HTTPS 强制\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>传输安全\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>加密与隔离\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>签名 URL 设有效期、CORS 白名单、Referer 防盗链、CDN 加速\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>数据保护\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>可恢复性优先\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>版本控制、跨区域复制、谨慎配置生命周期规则\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>上传安全\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>多层校验与隔离\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>扩展名白名单 + 文件头校验、文件重命名、存储与访问域名分离、安全响应头\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>\u003Cstrong>3. 执行层：检查清单化，形成团队规范\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>安全不是一次性的配置动作，而是需要持续执行的工程实践。\u003C\u002Fstrong>\u003C\u002Fspan>建议将文末的检查清单纳入团队的 Code Review 和上线流程，通过 CI\u002FCD 流水线集成自动化扫描（如 gitleaks），将\"人治\"转化为\"机制\"，确保每一项安全措施都能真正落地。\u003C\u002Fp>\n\u003Cp>对象存储是现代 IT 架构的基石，而安全是基石的底座——\u003Cspan>\u003Cstrong>凭证管理守住入口，权限控制划定边界，配置基线筑牢防线，上传校验封堵漏洞，检查清单确保执行\u003C\u002Fstrong>\u003C\u002Fspan>。五管齐下，方能在大海般的数据中守住安全底线。\u003C\u002Fp>","〇、前言 OSS 作为海量数据的承载平台，一旦配置不当，可能引发敏感数据泄露、恶意文件上传、巨额流量盗刷甚至数据被勒索加密等严重后果。 了解这些风险并非杞人忧天，而是帮助开发者和运维人员在使用 OSS 时建立正确的安全思维——从凭证管理、权限控制、访问策略到上传校验，每一个环节都可能在疏忽中成为攻击入口。 只有提前识别风险、主动防御，才能确保数据在享受云存储便利的同时，始终处于安全可控的状态。 那么本文就来简单介绍下什么是 OSS，以及如何规避常见的风险，供参考。 一、关于：对象存储服务（Object Storage Service） 1.1 简介 对象存储服务（简称 OSS 或 OBS 等）是云计算时代专为海量非结构化数据设计的分布式存储解决方案。 1）为什么需要对象存储？ 在互联网时代，产生了海量的非结构化数据（如：图片、视频、日志、备份文件等）。传统的存储方式在面对这些数据时暴露出明显的瓶颈： 块存储（如：硬盘）：扩展性差，跨节点扩展困难，且不支持原生共享，通常用于数据库或虚拟化平台。 文件存储（如：NAS）：虽然支持共享，但采用层级目录结构，当目录内文件极多时性能会严重衰减，扩展性受限。 对象存储正是为了克服上述缺点而诞生的。它摒弃了传统的层级目录结构，采用扁平化命名空间，将数据与元数据封装在一起，通过分布式架构实现了近乎无限的横向扩展。 2）核心概念解析 要使用对象存储，必须掌握以下三个最核心的概念： Bucket（存储空间\u002F桶） 它是对象存储的顶层容器，类似于传统文件系统中的“根目录”，但内部是扁平的，没有真正的子目录。 每个 Bucket 都有全局唯一的名称，且创建后所属区域不可更改。 Object（对象） 这是存储的基本数据单元。一个对象由三部分组成： Key（键名）：对象的唯一标识符，类似文件路径（如：images\u002F2025\u002Fphoto.jpg）。 Value（数据）：实际的二进制数据内容（图片、视频、文本等），对象存储不关心其内部格式。 Metadata（元数据）：描述数据的属性。包括系统自动生成的（如：文件大小、类型）和用户自定义的（如：作者、项目名），可用于业务分类和检索。 Endpoint（访问域名）与 AccessKey（访问密钥） Endpoint：对外服务的访问域名，不同地域的 Bucket 对应不同的 Endpoint。 AccessKey：用于身份验证的密钥（包含 ID 和 Secret），确保只有授权用户才能访问数据。 3）对象存储 vs 文件存储 vs 块存储 这三种存储的核心区别在于数据的组织方式和访问接口。以下是它们的对比： 维度 块存储 文件存储 对象存储 数据单位 固定大小的块（512B~4KB） 文件 + 目录层级 对象（数据 + 元数据 + Key） 访问接口 SCSI \u002F iSCSI \u002F FC POSIX（open\u002Fread\u002Fwrite） RESTful API \u002F SDK 扩展性 垂直扩展为主 中等，受索引性能限制 【无限横向扩展】 共享性 不支持原生共享 支持网络共享 【跨平台跨地域共享】 随机写 【支持】 【支持】 【不支持】（只能整体覆盖） 典型用户 数据库、虚拟化平台 办公文档、视频编辑 云原生应用、CDN、数据湖 一句话选型指南：追求低延迟、高 IOPS 选块存储；需多用户共享、目录管理选文件存储；海量数据、云原生、跨地域分发选对象存储。 1.2 对象存储的核心优势与应用场景 OSS 的三个核心优势。 1）高可靠性与持久性：通过多重冗余架构，主流云厂商的对象存储数据持久性可达 99.9999999999%（12 个 9），数据几乎不会丢失。 2）低成本与弹性：无需前期硬件投资，按需付费。支持生命周期管理，自动将冷数据转为低成本存储类型。 3）强一致性：现代对象存储（如：AWS S3、阿里云 OSS）已支持强一致性，写入成功后立即可读，不存在中间状态。 典型应用场景： 静态资源托管与分发：网站\u002FApp 的图片、音视频、CSS\u002FJS 文件存放在对象存储，结合 CDN 实现全球加速，大幅减轻源站服务器压力。 海量数据备份与归档：数据库备份、系统日志、医疗影像等长期保存的数据，可利用归档存储类型大幅降低成本1。 大数据与 AI 数据湖：作为底层存储，存放 AI 训练数据、模型文件和大数据分析结果，支持 PB 级数据处理和高带宽下载。 内容分享与网盘应用：提供安全的文件直传、防盗链保护以及在线预览等功能，支撑各类 SaaS 应用。 总而言之，对象存储已经成为现代 IT 架构中不可或缺的基础设施。如果正在开发网站、App 等应用中，面临海量非结构化数据的存储与管理难题，将静态资源从传统服务器中剥离并迁移至对象存储，是优化架构、降低成本的最佳实践。 二、规避 OSS 安全风险的具体做法 2.1 凭证管理：从源头杜绝 AccessKey 泄露 这是日常开发中最高频、也最容易出问题的环节。以下是绝对禁止的做法。 在代码中硬编码 AccessKey（accessKeyId = \"LTAI5t...\"）。 在前端\u002FAPP\u002F小程序代码中嵌入任何形式的 AK。 将包含 AK 的配置文件提交到 Git 仓库。 不同的场景需要不同的策略，下面简单例举几个。 1）服务端应用（Java\u002FPython\u002FNode.js 等） 通过环境变量读取凭证，代码中只引用变量名。 部署时通过 .env 文件、配置中心（如：Nacos、Apollo）或云厂商的密钥管理服务（KMS）注入环境变量，而非写死在代码里。 2）前端\u002F移动端应用 前端绝不能持有长期凭证。正确做法是通过 STS 临时凭证实现。 前端向你的业务服务器请求临时凭证。 业务服务器调用 AssumeRole 接口，向 STS 服务申请一个有效期短（建议 15~60 分钟）的临时 Token。 前端拿到临时 Token 后直传 OSS。 前端 APP ──请求临时凭证──▶ 业务服务器 ──AssumeRole──▶ STS 服务 前端 APP ◀──返回临时Token── 业务服务器 ◀──返回STS Token── STS 服务 前端 APP ──使用临时Token上传──▶ OSS 3）ECS\u002F容器环境 如果在阿里云 ECS、ECI 或 ACK 上运行，直接使用实例 RAM 角色，通过元数据服务自动获取临时凭证，完全无需管理 AK。 # ECS 实例元数据服务自动获取 STS Token curl http:\u002F\u002F100.100.100.200\u002Flatest\u002Fmeta-data\u002Fram\u002Fsecurity-credentials\u002FYourRoleName 4）工程化防护手段 Git pre-commit hook：使用 git-secrets、gitleaks 或 trufflehog 等工具，在代码提交前自动扫描是否包含 AK 特征（如阿里云 AK 以 LTAI 开头），命中则阻止提交。 CI\u002FCD 流水线集成扫描：在构建阶段加入密钥泄露检测，作为质量门禁的一部分。 定期轮换：制定 AK 轮换计划（建议 90 天），通过 KMS 凭据管家实现自动轮转。 2.2 权限控制：最小权限原则落地 1）永远不用主账号 AK 主账号 AK 拥有所有云资源的完全控制权，一旦泄露后果不堪设想。务必创建 RAM 子账号，且每个应用\u002F服务使用独立的子账号。 2）自定义策略精确授权 不要用 AliyunOSSFullAccess 这种全量策略（仅限测试环境快速验证），生产环境应编写自定义策略，精确到具体 Bucket 和具体操作。 { \"Version\": \"1\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": [ \"oss:PutObject\", \"oss:GetObject\" ], \"Resource\": [ \"acs:oss:*:*:my-app-bucket\u002Fuploads\u002F*\" ] } ] } 上述策略只允许向 my-app-bucket 的 uploads\u002F 目录上传和下载文件，无法列举其他 Bucket、无法删除文件、无法修改权限。 3）STS 临时凭证也要限制权限范围 签发 STS Token 时，通过 Policy 参数进一步收窄临时凭证的权限，例如只允许上传到特定目录。 { \"Version\": \"1\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": \"oss:PutObject\", \"Resource\": \"acs:oss:*:*:my-app-bucket\u002Fuser-uploads\u002F${userId}\u002F*\" } ] } 2.3 Bucket 配置：开发阶段就要定好安全基线 1）创建 Bucket 时的检查清单 配置项 推荐值 说明 ACL 私有（private） 默认值，绝大多数场景不需要改 阻止公共访问 开启 默认已开启，防止误操作导致数据公开 版本控制 开启（重要数据） 误删\u002F误覆盖后可一键恢复 服务端加密 开启 数据落盘自动加密 HTTPS 强制 开启 拒绝 HTTP 明文传输 2）开发环境 vs 生产环境 隔离 使用不同的 Bucket 区分开发、测试、生产环境。 开发环境的 RAM 子账号不应有生产 Bucket 的任何权限。 Bucket 命名建议包含环境标识：myapp-dev-assets、myapp-prod-assets。 2.4 数据传输与访问安全 1）签名 URL 设置合理有效期 对外分享私有文件时，使用签名 URL 并设置合理的过期时间（建议不超过 3600 秒（1小时））。 2）强制 HTTPS 在 Bucket 的 Bucket Policy 中添加规则，拒绝所有非 HTTPS 请求，防止数据在传输过程中被窃听。 3）配置 CORS 白名单 如果前端需要通过 JS 直接访问 OSS，务必在 CORS 配置中限定允许的 Origin 为你的业务域名，而不是设置为 *。 2.5 防盗链与流量控制 1）Referer 防盗链 对于公共读的静态资源 Bucket，配置 Referer 白名单，仅允许自己的网站域名访问。 白名单：https:\u002F\u002Fwww.yourdomain.com、https:\u002F\u002F*.yourdomain.com。 勾选\"不允许空 Referer\"（防止直接在浏览器地址栏访问）。 2）搭配 CDN 使用 将 OSS 作为 CDN 的源站，日常访问走 CDN 缓存，减少 OSS 直接外网流量，同时 CDN 层可叠加额外的鉴权和防护能力。 3）用量告警 在控制台设置存储量、外网流量、请求次数的告警阈值，当出现异常飙升时第一时间收到通知。 2.6 数据保护：开发阶段就要考虑 1）版本控制 对存储重要业务数据的 Bucket 开启版本控制。上传同名文件时自动保留历史版本，误删后可一键恢复。 2）生命周期规则要谨慎 配置生命周期规则时，务必确认前缀范围： backups\u002F — 只作用于 backups 目录。 前缀为空 — 将作用于 Bucket 中所有文件，可能导致全部数据被自动删除或转储。 3）跨区域复制 核心业务数据建议开启跨区域复制，虽然这样增加了成本，但是可以尽量确保在一个地域发生故障时数据仍可访问。 2.7 另外一个细节：上传文件的类型限定 当 OSS 允许上传任意类型文件且不做限制时，会存在诸多风险，例如： 1）上传恶意 HTML\u002FJS 文件（如：\u003Cscript>alert(document.cookie)\u003C\u002Fscript>），若通过同源域名直接访问，浏览器会执行其中的脚本，形成存储型 XSS。 2）上传 .exe、.apk、.sh 等可执行文件，借助受信任的 OSS 域名进行恶意软件分发，用户因信任域名而放松警惕。 3）上传 .svg、.xml 等文件，其中可嵌入脚本代码，同样触发 XSS。 4）利用 Flash\u002FPDF 等富媒体文件的漏洞，进行更复杂的攻击。 核心问题在于：OSS 域名被视为“可信源”，一旦攻击者在该域名下植入恶意内容，浏览器的同源策略反而会“保护”这些恶意代码的执行。 以下是一种多层解决方案。 1）上传阶段——严格校验文件类型 白名单机制（最关键）。只允许业务需要的文件类型通过，拒绝一切未明确允许的类型。 using System; using System.Collections.Generic; using System.IO; \u002F\u002F 允许的扩展名白名单 private static readonly HashSet\u003Cstring> AllowedExtensions = new(StringComparer.OrdinalIgnoreCase) { \"jpg\", \"jpeg\", \"png\", \"gif\", \"pdf\", \"doc\", \"docx\", \"xlsx\", \"mp4\" }; public bool IsAllowed(string filename) { \u002F\u002F Path.GetExtension 返回带 \".\" 的扩展名，如 \".jpg\"，需要去掉前导点 string ext = Path.GetExtension(filename).TrimStart('.').ToLower(); return AllowedExtensions.Contains(ext); } Content-Type 校验。不能仅依赖客户端传入的 Content-Type（可伪造），需结合文件扩展名和服务端检测。 文件头（Magic Number）校验。读取文件的前几个字节，验证其是否与声明的类型一致，防止\"改扩展名\"绕过。 byte[] header = ReadFirstBytes(file, 4); if (!header.SequenceEqual(new byte[] { 0xFF, 0xD8, 0xFF })) { throw new SecurityException(\"文件内容与声明类型不符\"); } 文件大小限制。设置合理的上传上限，防止大文件耗尽存储资源或造成 DoS。 2）存储与访问阶段——隔离与降权 存储 Bucket 与访问域名分离（极其重要） 业务域名（如：www.example.com）：用于提供页面，携带 Cookie、登录态。 OSS 访问域名（如：files.oss-cn-xxx.aliyuncs.com 或独立的 cdn.example-files.com）：专门用于访问上传的文件。 两者必须使用不同的域名，确保即使 OSS 上的文件包含恶意脚本，也无法读取业务域名下的 Cookie 和 Session。 禁止 OSS 域名直接渲染可执行内容 对用户上传的文件，访问时通过响应头强制浏览器以下载方式处理，而非直接渲染：Content-Disposition: attachment; filename=\"xxx.pdf\"。 或者对图片等需要在线展示的类型，使用图片处理服务（如 OSS 的图片缩放参数）返回处理后的图片，而非原始文件。 设置安全的 Cache-Control 和 CSP 在 OSS 或 CDN 层为文件设置安全响应头： Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; img-src data: X-Content-Type-Options: nosniff 文件重命名 上传后使用随机 UUID 重命名文件，避免攻击者通过文件名预测路径或利用特殊文件名（如：index.html）覆盖关键文件。 3）运行时防护 定期扫描与清理。对已存储文件进行定期安全扫描，检测是否存在可疑内容。 访问日志与异常监控。监控 OSS 访问日志，对异常流量（如大量下载、异常 User-Agent）进行告警。 三、一个简单的检查清单 如下检查项，可以纳入团队的 Code Review 和上线流程。 □ 代码中是否存在硬编码的 AccessKey？（用 gitleaks 扫描） □ 前端\u002F移动端是否使用了 STS 临时凭证而非长期 AK？ □ 新建 Bucket 的 ACL 是否为私有？ □ RAM 策略是否遵循最小权限原则？ □ 签名 URL 的有效期是否合理（≤ 3600 秒）？ □ 是否配置了 Referer 防盗链？ □ 是否开启了用量告警？ □ 重要 Bucket 是否开启了版本控制？ □ 生命周期规则的前缀范围是否正确？ □ 删除 Bucket 前是否已清除 CNAME 域名解析？ 四、小小的总结 本文从对象存储的基础概念出发，系统梳理了 OSS 在实际使用中面临的安全风险及对应的规避策略，核心要点可归纳为以下三个层面： 1. 认知层：理解对象存储的本质与边界 对象存储以扁平化命名空间和 RESTful API 为核心，天然适合海量非结构化数据的存储与分发，但在随机写、事务一致性等方面存在固有局限。选型时应根据业务特征在块存储、文件存储与对象存储之间做出合理取舍，避免\"用错工具\"带来的架构隐患。 2. 安全层：将安全左移，嵌入开发全流程 OSS 安全风险的根源大多不是产品缺陷，而是配置疏忽与开发习惯。贯穿全文的安全实践可浓缩为以下关键原则： 安全维度 核心原则 关键动作 凭证安全 凭证不落代码 环境变量\u002FKMS 管理、STS 临时凭证、Git Hook 扫描 权限控制 最小权限原则 RAM 子账号、自定义策略精确授权、STS 进一步收窄 资源基线 创建即安全 私有 ACL、阻止公共访问、版本控制、服务端加密、HTTPS 强制 传输安全 加密与隔离 签名 URL 设有效期、CORS 白名单、Referer 防盗链、CDN 加速 数据保护 可恢复性优先 版本控制、跨区域复制、谨慎配置生命周期规则 上传安全 多层校验与隔离 扩展名白名单 + 文件头校验、文件重命名、存储与访问域名分离、安全响应头 3. 执行层：检查清单化，形成团队规范 安全不是一次性的配置动作，而是需要持续执行的工程实践。建议将文末的检查清单纳入团队的 Code Review 和上线流程，通过 CI\u002FCD 流水线集成自动化扫描（如 gitleaks），将\"人治\"转化为\"机制\"，确保每一项安全措施都能真正落地。 对象存储是现代 IT 架构的基石，而安全是基石的底座——凭证管理守住入口，权限控制划定边界，配置基线筑牢防线，上传校验封堵漏洞，检查清单确保执行。五管齐下，方能在大海般的数据中守住安全底线。",7030,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":39},"2026 · 数据与架构","#2563eb","16 \u002F 10",[18],{"targetType":8,"targetId":9,"likedByMe":41,"likeCount":42,"commentCount":42,"contentLikeCount":42,"contentCommentCount":42,"sourceLikeCount":42,"sourceCommentCount":42},false,0,[44,51,58,64,70,79,85,92],{"id":45,"kind":7,"title":46,"summary":47,"image":48,"href":49,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":50},"NEWS_ARTICLE:842","几何分布：从“等一个结果”开始","你有没有过这样的经历？ 在游戏里抽卡，抽了多少次才终于出货？ 站在路边等公交车，第几辆来的才是你要坐的那一路？ 给客户打电话，打到第几个才终于接通？ 刷短视频时，刷了多少条才刷到自己想看的内容？ 这些场景背后，都藏着一个共同的概率模型——几何分布（Geometric Distribution）。 几","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F83005\u002F202609\u002F83005-20260902112922617-1277310049.png","\u002Fnews\u002F842",[18],{"id":52,"kind":7,"title":53,"summary":54,"image":55,"href":56,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":57},"NEWS_ARTICLE:892","zg 正式开源：本地检索，不止于关键词","🚀 zg（zvec-grep）正式开源！\n　\n我们打磨了一款面向人与 AI Agent 的「本地检索工具」——  \n默认在本机完成索引与检索，既能理解模糊意图，也保留 rg 的精确与高效。\n　\n🔒 本地优先：文件处理、索引和检索均在设备内完成，代码与文档无需上传，保护隐私与数据安全。\n　\n⚡️","https:\u002F\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fpng\u002F24957442\u002F1786498962962-a148a454-6626-4fdc-81ff-e95a9f71c9cd.png","\u002Fnews\u002F892",[18],{"id":59,"kind":7,"title":60,"summary":61,"image":14,"href":62,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":63},"NEWS_ARTICLE:899","C# U9 二次开发","U9 是用友 U9 Cloud，基于BEAS 开发平台，底层 C# + .NET Framework，服务端是 IIS+WCF，数据库 SqlServer；二次开发分：插件扩展、WebService 接口、单据扩展、自定义页面、外部程序调用 U9 接口。 ⚠️ U9 二次开发不建议直接修改 U9 原","\u002Fnews\u002F899",[18],{"id":65,"kind":7,"title":66,"summary":67,"image":14,"href":68,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":69},"NEWS_ARTICLE:925","订单的含金量在分化","复杂的流程，在产品设计阶段就需要综合考虑多方面的建议，前期业务和技术的介入，避免产品层面出现合理但不合适的设计，过繁或者过简都不利于整体的迭代节奏。","\u002Fnews\u002F925",[18],{"id":71,"kind":7,"title":72,"summary":73,"image":74,"href":75,"meta":76,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":77},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[78],"人工智能",{"id":80,"kind":7,"title":81,"summary":82,"image":14,"href":83,"meta":17,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":84},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":17,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":91},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":93,"kind":7,"title":94,"summary":95,"image":14,"href":96,"meta":97,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":98},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[99],"软件开发"]