国内唯一,阿里云入选全球区块链云服务报告,领先AWS、Google
近日,知名调研机构Gartner发布了全球领先公共云厂商区块链服务能力报告,作为唯一上榜的中国科技公司,阿里云获得六个评判维度的最高分,排名第二,仅次微软,领先AWS、Google等企业。
近日,知名调研机构Gartner发布了全球领先公共云厂商区块链服务能力报告,作为唯一上榜的中国科技公司,阿里云获得六个评判维度的最高分,排名第二,仅次微软,领先AWS、Google等企业。
本文详细介绍了在 AWS 上快速搭建生产级 EKS 集群的步骤,包括子网规划、IAM 配置、必要命令工具的安装以及集群的创建和授权。通过 `eksctl` 工具快速定义和创建 EKS 集群,并提供了集群权限管理与网络配置的建议,确保集群安全和稳定运行。文中还包含完工后的调整建议,如将访问端点调整为私有以提升安全性。
本文介绍了如何使用 `sigma` 替代 AWS 的 ECR 作为轻量级的镜像仓库解决方案。通过配置 `s3` 存储、端口监听等设置,实现了低资源占用下的高效镜像管理。文章详细提供了 `config.yaml` 文件的配置方案,以及 `sigma` 部署的具体步骤,适合在自建环境中替代 ECR 进行镜像管理。
如果你的业务场景有多个 AWS 账号,那么私有域共享就是一个绕不开的话题。aws 中的 route53 私有域配置跨账号共享有两种方案,一种是直接跨账号关联 VPC,一种是通过配置文件共享的形式实现。本文采用第一种方案,只需要两条命令即可完成此需求。
本文详述了 AWS 网络环境的规划,包括 VPC、子网、路由表的创建和管理。通过对公有、私有和内部子网的划分,以及 NAT 网关和 IGW 的配置,实现了不同网络的隔离与访问控制。同时,文章介绍了使用中转网关进行跨账号 VPC 打通的方法,为多账号和复杂网络环境提供了便捷的连接方案。这些规划为 AWS 运维部署打下了基础,有助于提升环境的安全性与可扩展性。
我们的部分后端服务正在经历容器化的改造, 由于历史包袱,现网的网关等设施无法一次性迁移到 k8s 集群中, 因此使用 Nginx proxy_pass 转发到 AWS ALB 这样一个曲线救国的临时方案。
但是在使用时,我们发现一段时间后 Nginx 出现了 504 的错误,检查后端服务均是正常的,而单独访问 ALB 也是正常响应的,因此便有了此文。
我们的部分后端服务正在经历容器化的改造, 由于历史包袱,现网的网关等设施无法一次性迁移到 k8s 集群中, 因此使用 Nginx proxy_pass 转发到 AWS ALB 这样一个曲线救国的临时方案。
但是在使用时,我们发现一段时间后 Nginx 出现了 504 的错误,检查后端服务均是正常的,而单独访问 ALB 也是正常响应的,因此便有了此文。
尽管Serverless架构在某些方面表现出色,但在当前轰轰烈烈的“微服务”进程中,它仍然不是一种主要的选择。除了由于本身特性导致的使用场景受限外,我想乏善可陈的关于Serverless最佳实践的总结也是一个重要的因素。
最近, Google 账户新增了一种叫做 passkey 的登录方式。
和 密码 + U2F 的验证方式相比,passkey 实际上类似于在手机等设备上实现了一个 U2F,并使用它代替了两者的组合。对于普通用户来说这固然是比只用密码要安全的多的(因为 passkey证明了用户拥有一个登录了该 Apple ID 或 Google 账户的设备,并且知道其解锁密码,或是向设备以生物信息证明了身份),但由于完全去掉了密码,设备本身的安全性就很重要了,在 Google 的实现中 ,锁屏密码用于生成端到端加密的密钥,因此一个能够登录 Google 账户,并且获知了锁屏 PIN 的人便能恢复出 passkey。根据文章的说法,通过硬件保证了 PIN 只能尝试最多十次,但总体上,无论是 Google 还是 Apple 的实现都依赖于一直在线的手机本身的安全性,而 U2F 设备通常并不是连接在设备上的,因此我认为尽管对普通人来说passkey 已经足够好,但对于需要持续提高电击电压的人群来说,使用 密码 + U2F 会更安全一些。
虽然通常很容易构建能够正常运作的软件, 但更难的是确定没有人能够以不是预期的方式使用它。
Solidity中,这更加重要,因为你会使用智能合约来 控制token,甚至可能是更加宝贵的东西。 此外,每次 智能合约的执行,都是公开的。并且, 代码也常常是开源的。
当然,你总是必须考虑这个问题有多大: 你可以用一个web服务来和智能合约进行对比,这个web服务向公众开放 (也可能是向恶意攻击者),甚至可能是开源的。 如果您只是在那个web服务上存储您的杂货列表, 您可能没有必要 关心太多,如果你使用这个web服务处理你的银行账户, 你应该更加谨慎。
本节将列出一些陷阱和一般安全建议,但 当然,永远不可能是完整的。 还有,请记住,即使你的智能 合约代码是没有bug的,编译器或平台本身可能有一个 bug。 编译器中一些已公开的安全错误列表 可以在 :ref:list of known bug<known_bugs>中找到, 这也是 机器可读的。 注意有一个覆盖Solidity编译器的代码生成器的 bug bounty 程序 。