自动驾驶_无服务器安全性：将其置于自动驾驶仪上

自动驾驶

Ack ：本文是从个人经验以及从无服务器安全性的多个其他来源中学到的东西的混合体。 我无法在此处列出或确认所有这些内容； 但是，应该特别感谢The Register ， Hacker Noon ， PureSec以及Serverless Status和Serverless(Cron)icle新闻通讯。

我们都喜欢想象我们的系统是安全的。 接着…

破！！！

每个开发人员，系统管理员和最终CISO都面临一个非常普遍的噩梦。

必然？

计算机安全的一项基本原则指出， 没有系统可以达到绝对安全。 就像人一样： 没有人是完美的。 除非与外界完全隔离，否则不可以。 按照当今的标准，这几乎是不可能的–此外，拥有一个不能接受输入和提供输出的系统的意义何在？

无论您采取何种高级安全防护措施，攻击者最终都将找到解决方法。 即使您使用具有最大可能密钥长度的最严格的加密算法，攻击者最终也会通过蛮力进行攻击。 尽管目前在时间上是不可行的，但谁又能保证在技术上取得突破，明天或第二天就有可能呢？

但这并不是您真正要担心的暴力手段： 人为错误更为常见，并且可能对系统安全性造成破坏性影响； 比暴力破解的密码要重要得多。 看看这个故事，有些人走进美国国税局大楼，building走了数百万美元，却没有使用任何所谓的“黑客”技术。

只要系统是由人制造和操作的，他们就天生就是容易出错的人，那么它们将永远不会真正安全。

那么，我们注定要失败吗？

没有。

见过船的内部吗？

它的船体如何划分成多个舱室，以便一个泄漏的舱室不会导致整艘船沉没？

人们通常在设计软件时采用类似的概念：多个模块，这样一个受损的模块就不会导致整个系统瘫痪。

结合最小特权原则，这意味着组件将损害最小程度的安全性-理想情况下，攻击者将只能在模块安全范围的范围内造成破坏，永远不会超出范围。

减小组件的爆炸半径，从而减小整个系统暴露的冲击面。

您可以说是一个安全沙箱。

那是一个相当不错的。

PoLP：最小特权原则

绝对不要给某人(或某物)比他们所需的更多的自由。

更正式地说，

每个模块必须只能访问其合法目的所需的信息和资源。 – 维基百科

这样，如果模块行为异常(或被具有恶意意图的实体(黑客，用英语)强迫行为)，则可以将其引起的潜在危害降到最低； 没有采取任何预防性的“行动”，甚至在识别出“违规”之前！

它永远不会变老

尽管该原则最初是在遗留系统的上下文中提出的，但它更适用于“现代”架构。 SOA(嗯，也许不是那么“现代”)，微服务和FaaS(无服务器功能，因此也就是无服务器安全性)。

这个概念非常简单：使用底层访问控制机制来限制“执行单元”可用的权限； 可能是简单的HTTP服务器/代理，Web服务后端，微服务，容器或无服务器功能。

同时，在没有服务器的地方……

随着无服务器技术在全球范围内的广泛采用，无服务器安全性的重要性以及我们PoLP的价值变得比以往更加明显。

少服务器=省力

无需配置和管理服务器(环境)意味着无服务器开发可以以惊人的速度进行。 有了CI / CD，这只是代码，提交和推送的问题； 几分钟之内，一切就可以启动并运行，即使不是几秒钟。 没有SSH登录，文件上传，配置同步，服务重启，路由更改或与传统部署相关的其他烦人的琐事。

“让我们稍后修复权限。”

las，在那些“无ops”开发人员(如我自己)中，这是很常见的事情。 您急于将最新的更新推送到暂存中，而避免过多“拒绝权限”错误的“简便之路”是放宽对FaaS实体( AWS Lambda ， Azure Function等)的权限。

分期将很快迁移到产品。 您的“超权限”功能也将如此。

它会留在那里。 远远超出您的想象。 最终，您会将流量转移到更新版本，而保留旧版本不变。 担心会破坏其他一些从属组件，以防您踩到它。

然后是时间的沙土，从每个人的记忆中掩盖了旧功能。

具有未打补丁的依赖关系和可能有缺陷的逻辑的过时功能，可以完全访问您的云资源。

无服务器定时炸弹，如果有的话。

再次！

如果我们从分阶段部署开始就遵循最小特权原则，它将极大地减小爆炸半径：通过限制允许执行的功能，如果系统的其余部分受到“利用程度”的限制，我们将自动对其进行限制控制曾经落入错误的手中。

完善无服务器安全性：在公共云平台上

这些事情说起来容易做起来难。

目前，在公共云FaaS技术的领导者中，只有AWS具有足够灵活的无服务器安全模型。 GCP会自动为给定项目中的所有功能分配一个默认的项目级Cloud Platform服务帐户，这意味着就安全性和访问控制而言，所有功能都将集中在一个篮子中。 Azure的IAM模型看起来更有希望，但是它仍然缺少诸如AWS和GCP中可用的基于角色的自动运行时凭据自动分配之类的炫酷功能。

AWS已为其Lambda函数应用了自己的基于IAM角色的权限模型，从而使用户可以灵活地为每个Lambda函数定义具有完全可自定义权限的自定义IAM角色(具有完全可自定义的权限)。 它具有令人印象深刻的一系列预定义角色，您可以在这些角色上进行扩展，并具有定义明确的策略，用于对资源或主体类别进行权限范围界定，合并引用同一组资源或操作的规则等。

整个层次最终归结为一组权限，每个权限采用一种相当简单的格式：

{
    "Effect": "Allow|Deny",
    "Action": "API operation matcher (pattern), or array of them",
    "Resource": "entity matcher (pattern), or array of them"
}

用英语，这仅意味着：

允许(或拒绝)拥有此许可权的实体(用户，EC2实例，lambda；无论如何)对匹配的资源执行匹配的API操作。

(也有非强制性的“ Principal和“ Condition字段，但为简洁起见，我们在此处将其跳过。)

现在来看一些例子。

{
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::my-awesome-bucket/*"
}

这允许受让人将一个对象( s3:PutObject )放入名为my-awesome-bucket 。

{
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::my-awesome-*"
}

这是相似的，但允许在名称以my-awesome-开头的任何存储桶上执行my-awesome- 。

{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
}

这允许受让人针对其拥有的AWS账户中的任何存储桶执行任何S3操作(获取/放入对象，删除对象，甚至删除存储桶)。

现在是银弹：

{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
}

是的，您可以自己对AWS账户中的任何内容执行任何操作。

有点像AdministratorAccess托管策略。

而且，如果您的主体(例如lambda)受到威胁，攻击者实际上就可以对您的AWS账户具有管理员访问权限！

无服务器的安全梦night。 不用说。

不惜一切代价避免。

期。

从这个意义上讲，最好的选择是一系列第一类权限； 允许范围最小(限制最大)且涵盖范围狭窄且定义明确的范围。

那有多难？

需要注意的是，您必须为该计算单元内的每个单个操作执行此操作(例如lambda)。 每一个。

当您需要配置事件源来触发这些单元时，情况会变得更糟。

例如，对于由API网关触发的lambda，必须授予API网关服务在特定APIG端点范围内(以CloudFormation 语法)调用您的lambda的权限：

{
  "Type": "AWS::Lambda::Permission",
  "Properties": {
    "Action": "lambda:InvokeFunction",
    "FunctionName": {
      "Ref": "LambdaFunction"
    },
    "SourceArn": {
      "Fn::Sub": [
        "arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${__ApiId__}/*/${__Method__}${__Path__}",
        {
          "__Method__": "POST",
          "__Path__": "/API/resource/path",
          "__ApiId__": {
            "Ref": "RestApi"
          }
        }
      ]
    },
    "Principal": "apigateway.amazonaws.com"
  }
}

或对于由Kinesis流支持的lambda，在这种情况下情况会变得更加复杂： Lambda函数需要访问以观看和从流中拉出，而Kinesis服务还需要权限才能触发lambda：

"LambdaFunctionExecutionRole": {
    "Type": "AWS::IAM::Role",
    "Properties": {
      "ManagedPolicyArns": [
        "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
      ],
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Action": [
              "sts:AssumeRole"
            ],
            "Effect": "Allow",
            "Principal": {
              "Service": [
                "lambda.amazonaws.com"
              ]
            }
          }
        ]
      },
      "Policies": [
        {
          "PolicyName": "LambdaPolicy",
          "PolicyDocument": {
            "Statement": [
              {
                "Effect": "Allow",
                "Action": [
                  "kinesis:GetRecords",
                  "kinesis:GetShardIterator",
                  "kinesis:DescribeStream",
                  "kinesis:ListStreams"
                ],
                "Resource": {
                  "Fn::GetAtt": [
                    "KinesisStream",
                    "Arn"
                  ]
                }
              }
            ]
          }
        }
      ]
    }
  },
  "LambdaFunctionKinesisTrigger": {
    "Type": "AWS::Lambda::EventSourceMapping",
    "Properties": {
      "BatchSize": 100,
      "EventSourceArn": {
        "Fn::GetAtt": [
          "KinesisStream",
          "Arn"
        ]
      },
      "StartingPosition": "TRIM_HORIZON",
      "FunctionName": {
        "Ref": "LambdaFunction"
      }
    }
  },
  "KinesisStreamPermission": {
    "Type": "AWS::Lambda::Permission",
    "Properties": {
      "Action": "lambda:InvokeFunction",
      "FunctionName": {
        "Ref": "LambdaFunction"
      },
      "SourceArn": {
        "Fn::GetAtt": [
          "KinesisStream",
          "Arn"
        ]
      },
      "Principal": "kinesis.amazonaws.com"
    }
  }

因此，您将看到，这种粒度带来了强大的力量和巨大的责任感。 一个丢失的权限(heck，一个错误键入的字母)，它是403 AccessDeniedException 。

没有简单的方法； 您只需要跟踪函数触发或访问的每个AWS资源，查找文档，梳理一下头发并获得必要的权限。

但是……但是……那是太多的工作！

是的，是的。 如果您手动进行。

但是，这些天谁来手动驾驶？ :)

幸运的是，如果您已经开始自动化，则有很多选择：

如果您在使用著名的无服务器架构-这意味着你已经涵盖在扳机上的权限前-还有的serverless-puresec-cli从插件Puresec 。

该插件可以静态分析您的lambda代码并生成最小特权角色。 看起来确实很酷，但是需要注意的是，在每次更改代码的部署之前，您必须运行serverless puresec gen-roles命令。 我还找不到自动运行它的方法-例如在serverless deploy期间。 更糟糕的是，它只是将生成的角色打印到stdout中。 因此，您必须手动将其复制粘贴到serverless.yml ，或使用其他伏都教将其实际注入到部署配置中(希望将来会有所改善：)

AWS圣杯：来自众神

如果您是Python迷， Chalice可以自动为您自动生成权限。 圣杯在很多方面都很棒。 超快速部署，注释驱动的触发器，需要维护的配置很少甚至没有，等等。

但是，尽管是从AWS众神直接获得的帮助，但它似乎在权限方面错过了“最小”一词。 如果您有列出某些存储桶foo 内容的代码，它将生成许可列出AWS账户中所有存储桶的内容( "Resource": "*"而不是"Resource": "arn:aws:s3:::foo/*" )，而不仅仅是您感兴趣的存储桶。不酷！

选择SLAppForge Sigma

如果您是初学者，或者不喜欢CLI工具， 可以使用SLAppForge的Sigma 。

作为成熟的浏览器IDE，Sigma会在您编写(键入或拖放)代码时自动分析您的代码，并为Lambda运行时和触发器获取必要的权限，因此您已全面了解。 最近引入的权限管理器还允许您根据需要修改这些自动生成的权限。 例如，如果您正在集成Sigma尚不了解的新AWS服务/运营。

另外，有了Sigma，您无需担心任何其他配置。 资源配置，触发器映射，实体相互关系等-IDE会处理所有这些。

需要注意的是，Sigma目前仅支持NodeJS。 但是Python，Java和其他很酷的语言正在兴起！

(如果您有其他凉爽的无服务器安全策略生成工具，请在下面发表评论！不， AWS Policy Generator不算在内。)

在结束时

最低特权原则对于无服务器安全和软件设计至关重要。 迟早会节省您的时间。 Lambda的高度精细的IAM许可模型非常适合PoLP。

Puresec CLI插件，多合一Sigma IDE和AWS Chalice等工具可以自动生成安全策略。 使您的生活更轻松，同时仍然遵守PoLP的承诺。

翻译自: https://www.javacodegeeks.com/2018/11/serverless-security-putting-autopilot.html

自动驾驶