自动驾驶行车记录仪训练集_无服务器安全性：将其置于自动驾驶仪上

自动驾驶行车记录仪训练集

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

我们都喜欢想象我们的系统是安全的。然后…

破！！！

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

无服务器安全

必然？

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

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

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

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

无服务器安全

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

没有。

见过船的内部吗？

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

人们通常在设计软件时采用类似的概念：多个模块，这样一个受侵害的模块不会使整个系统崩溃。

无服务器安全

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

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

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

那是一个相当不错的。

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/*" ），而不仅仅是您感兴趣的存储桶。不酷！