销售策略-从局部市场到全国范围，优秀SaaS公司的市场突破公式
06-18
虎符龙节随着云计算的蓬勃发展，云安全问题无疑成为重中之重，而AKSK无疑是云安全问题中不可忽视的一部分。被忽略。
AKSK本质上代表一种身份认证。作为云上最容易泄露但也是最敏感的数据，云平台对AKSK进行身份认证，以确认用户是否合法访问云平台以及可以访问哪些云。
资源。通过AKSK认证的用户可以在云平台的各种资源之间自由穿梭，在租户自身的权限下操作各种资源和数据。
近年来，因AKSK泄露而引发的各种网络安全和数据安全问题相继出现。 AKSK的泄露将直接导致云平台上用户的各种云资源被恶意操作修改。
的数据被恶意窃取，影响不小。 AKSK 安全风险示例 在所有 AKSK 泄露案例中，几乎都可以归结为以下原因： AKSK 安全存储方法缺失。
最直接的就是硬编码到业务代码中并上传到github。其次，配置文件中也有明文配置。
并在日志中任意打印等。AKSK服务隔离手段缺失。
例如，多个服务共享一对 AKSK。这样，任何一项服务造成的AKSK泄漏都会影响其他服务。
AKSK缺乏安全的传播方式，例如直接通过微信、企业微信等即时通讯工具进行AKSK的口碑传播。 AKSK的安全管理问题是一个技术问题，但绝对不仅仅是一个纯粹的技术问题。
这也是一个安全操作问题。技术能力只是掩盖底层的手段，有效的运营管理机制才是规避风险的前提。
。搅拌汤以阻止其沸腾是徒劳的。
当然，市面上并不是没有AKSK保护方法，但其效果有限，后果无穷。比较常见的“强硬战术”之一就是直接限制AKSK的源IP，只允许白名单中的IP访问。
这种方法的效果是立竿见影的。然而，作为一个已经迁移到云端的业务，用这样一种“老式”的方式来保护AKSK已经失去了云计算应有的灵活性和可扩展性。
真是浪费了芝麻，损失了西瓜。当然，还有另一种直接的方式，比如将AKSK绑定到云服务器上。
云服务器的各种系统信息都可以作为指纹参与AKSK身份认证的计算。由于云服务器有完整的操作系统，即使关机重启，也不需要像docker pod那样担心环境信息的变化，这确实是一个有效的措施，但一方面，它需要云平台提供AKSK与云服务器绑定的能力。
另一方面，基本上相当于放弃了docker环境下Possibility中的业务部署。不用说，将业务部署在docker上的好处是比云服务器成本更低、扩展性更好、环境一致性更强。
对于以商业利润为最终目标的企业来说，是一个不可忽视的诱惑。当然，也有人认为，既然如此，我们就应该自己保护它。
比如我生成一个密钥，自己用该密钥加密AKSK，自己保存该密钥。这不行吗？那么，这里我们必须承认，AKSK本身的加密保护是一个值得探索的方向，也一定是一个最终需要实践的方向。
但是，如果您生成自己的 AKSK 加密密钥，则风险实际上会转移到密钥的安全性上。现在有互联网的国家基本上都有自己的加密法和信息安全法，我国也不例外。
无需遍历所有现有法律法规来证明什么样的密钥是安全的。事实上，我们对于关键安全问题有一个最基本的门槛，那就是：你的密钥是由国家密码动物局认证的设备生成并保护的。
仅此一点就可以扼杀大部分通过自生成密钥加密敏感数据的想法。话虽如此，如果你真的拥有自己的经国家密码动物局认证的加密机，并且自己搭建了完整的密钥管理系统，那么你确实可以生成自己的密钥来保护你的AKSK，但这涉及到成本再次，对于一个以商业利润为最终目标的企业来说，这种成本和长期的运维消耗可能是难以承受的负担。
也有人认为需要依靠云平台的能力，不能只是闭门造车。比如很多时候人们总是会问，我的AKSK可以通过腾讯云的KMS系统进行加密吗？这其实就陷入了先有鸡还是先有蛋的循环。
要知道KMS本身也是腾讯云的产品。如果你使用KMS来保护你的AKSK，那么当你想要解密它时，你必须访问KMS，对吗？当你访问KMS时，你需要明文AKSK，对吗？好像AKSK的保护问题没有解决？上述保护AKSK的困难和问题如此之多，难道就真的没有办法保护了吗？一定有办法的！只是我们必须改变我们的想法。
如果我们不打破它，我们就不会建造它！我们不妨从更高的角度来看待这个问题。假设我们不再使用AKSK作为云平台的基础凭证，而是将其作为云平台可以为我们管理的某种数据资产。
这时候，必然又出现一个问题。前面分析过，如果云平台上保护了AKSK，那么访问云平台是不是也需要AKSK呢？这个 AKSK 从哪里来？其实很简单：使用另一个AKSK来访问。
之前我们分析过，对于AKSK保护场景，其实需要一定的运行机制的协助。技术手段并不能从根本上解决这个问题。
这时，我们不妨顺理成章地推导出这样一个想法：首先，毫无疑问，云资源可以通过授权账户来管理访问权限，这是基础之一；其次，很明显，现在成熟的云平台必须允许根账户生成子账户，并且每个子账户的访问权限本身都可以由根账户设置，这是第二个基础。基于以上两个基础，我们大胆一点假设，我们将业务所需的AKSK数据存储在云平台上，成为凭证资源；然后，我们生成一个具有有限权限的子帐户。
该子账户被授权只能读取某个凭证资源；当业务需要访问某些云资源时，首先需要使用小权限AKSK拉取托管凭证，然后根据托管凭证中的AKSK来访问云资源；分权示意图现在看起来有点混乱，但是新的问题又出现了。如何保护权限较小的子账户的AKSK？兜了一圈之后，问题似乎又回到了原点？大事：基于腾讯云SSM和白盒密钥的综合解决方案。
说了这么多，终于可以进入正题了。我们已经讨论了一个看起来可行的解决方案：将问题从保护大权限的 AKSK 转变为保护小权限的 AKSK。
我们不要在这里兜圈子。推荐的解决方案是将子账户的职责拆分为三个独立的权力，结合SSM的安全托管能力，同时在不可信环境下使用白盒密钥以较小的权限控制AKSK。
达到对AKSK进行安全保护的效果。上述分权及核心业务流程的步骤可以描述如下： 代码语言：c++ 复制 1、使用主账户创建只写子账户和只读子账户 2、使用只写账户在SSM上创建自定义凭证A，其中存储用户的真实业务AKSK。
3. 对只读账户进行CAM授权，并明确限制只读账户只能访问Credential A。 4. 使用主账户生成只读子账户的AKSK。
5、使用腾讯云KMS白盒密钥产品对只读子账户的AKSK进行加密。 6、将步骤4生成的密文、白盒解密SDK及相关IV交付给业务。
7、业务启动流程时，首先通过白盒密钥解密AKSK密文，获取只读子账户的AKSK明文。然后通过只读子账户的AKSK访问Credential A，获取Credential A的明文。
8、业务获取到Credential A的明文后，使用业务中的业务明文AKSK进行访问真实的商业资源。业务系统及流程拆解图 业务流程拆解 操作流程功能说明 关于白盒按键 接下来我们花一点篇幅来科普一下白盒按键。
白盒密钥白盒加密与传统对称加密的区别在于白盒密钥和算法被混淆，白盒解密密钥中不存在密钥的明文。传统的加密方法中，密钥必须完整出现才可以正常解密。
为了正常解密，必须保证密钥完全出现在不可信的环境中。这时，无论你如何隐藏密钥，即使编译成二进制动态库，攻击者都可以分析出完整的密钥明文，并且只要攻击者获得了密钥明文，由于传统加密算法的开放性，攻击者甚至可以编写自己的解密程序来正常解密密文。
举个例子，IV的保存也存在这样的问题。白盒加密技术将算法和密钥深度融合，对密钥进行复杂的数学运算，然后将密钥信息隐藏在二进制混淆密钥库中。
在程序运行的任何阶段，密钥都以一个巨大的查找表的形式存在，并且密钥在任何情况下都不会以明文形式出现，这样可以有效隐藏密钥。同时，在整个过程中，原始密钥始终被加密隐藏，不会存在于内存中，从而防止密钥被静态分析和动态调试。
黑客想要解密，必须获得完整的二进制混淆密钥文件和白盒SDK。否则，使用传统的对称加密算法无法解密密文。
这种保护机制可以有效抵御不可信环境下的密码攻击。这种方法增加了破解密文的难度。
看到这里读者可能还有疑问。当我使用白盒密钥解密时，我不需要AKSK吗？答案是：不再了。
因为一旦客户使用白盒密钥完成加密，密文、密钥和白盒SDK就可以离线工作。不再依赖云平台的解密能力。
关于SSM 凭证管理系统（Secrets Manager，SSM）基于密钥管理系统KMS，为用户提供凭证的创建、检索、更新、删除等全生命周期管理服务，并结合资源级角色授权轻松实现敏感凭证的统一管理。 。
针对敏感配置和敏感凭证明文编码带来的泄露风险，用户或应用程序可以通过调用Secrets Manager API/SDK查询凭证，可以有效避免程序硬编码和明文配置导致的敏感信息泄露和权限丢失。商业风险。
SSM使用KMS主密钥CMK作为加密密钥，以Name-Value格式存储各类数据。 Value部分支持最大字节，如数据库连接、账户密码、IP端口等托管凭证内容的加密存储。
使用凭据时，SDK 将通过 TLS 将数据安全地本地传输到服务器。关于KMS密钥管理系统 KMS是基于硬件加密机的云密钥管理系统。
主要提供以下核心服务： 密钥加解密算法（AES、国密SM4）真随机数密钥全生命周期管理轮换等用户密钥由加密机安全控制。国内区域密钥使用国密算法SM4加密，海外区域使用AES加密，满足不同区域的合规要求。
关于只读和只写子账号CAM策略的设置，只读子账号的策略内容模板如下： 代码语言：json copy { "version": "2.0", "statement": [ { "effect": "allow", "action": [ "ssm:GetSecretValue" ], "resource": [ "qcs::ssm::uin/${主账户 UIN}:secret/creatorUin/${resource Creator UIN}/${资源ID} " ] } ]} 其中：${主账户UIN}替换为主账户的UIN ${资源创建者UIN}替换为新创建子账户的UIN ${仅在SSM中使用新创建的凭证名称编写子账户的策略内容模板如下： 代码语言：json copy { "version": "2.0", "statement": [{ "effect": "总结一下AKSK的安全防护，本质上其实属于垂直切分场景在数据安全领域。随着人工智能、大数据、云计算等方向的动荡甚至野蛮发展，数据安全本质上已发展成为多维度、多场景的问题。
做好数据安全很难！向更多的中小企业甚至个人云租户提供数据安全即服务更是难上加难！这种困难不仅来自于技术，更多的时候来自于人本身。无论系统多么精密复杂，最大的安全风险始终是人本身。
正如本文前面提到的，保护AKSK不仅需要技术水平，还需要相应匹配操作系统的协助。然而，不仅是在AKSK的情况下，而且在存在安全问题的情况下，我们应该记住，制度和规则的建立有其自身的原因。
我们在工作中应该用严谨、理性的态度来约束自己。 ，不要让我们人类成为一个容易被攻破的安全漏洞。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
06-17
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用