Temos um aplicativo móvel com funcionalidade de inscrição (pense nele como um lambda da AWS), que é acessível publicamente.
Durante o desenvolvimento, implantamos em uma conta AWS sandbox. Queremos que o sistema dev proíba a inscrição pública, mas ainda permita que o desenvolvedor se inscreva por meio de um front-end especificamente configurado (ou seja, com as chaves secretas necessárias).
O raciocínio para isso é que não queremos que atores maliciosos consigam falar com nossos sistemas de desenvolvimento! Como estamos fazendo serverless, é difícil aplicar isolamento em nível de rede, então toda a segurança deve vir da autenticação. Também queremos manter a maioria do trabalho de autenticação e autorização para o IAM porque chamadas não autorizadas para lambdas não incorrem em custo.
Minha solução atual é:
Na produção, anexe uma política baseada em recursos à função Lambda de inscrição, permitindo explicitamente a invocação pública (Principal: "*")
para lambda:InvokeFunction
.
Em desenvolvimento, anexe uma Deny
declaração às funções Lambda marcadas com dev_protect = true
. Esta regra de negação bloqueia a invocação se o chamador não tiver uma tag principal developer = true
. Adicione esta tag às funções do desenvolvedor, que o front-end usa para inscrição.
Aqui está o exemplo das políticas:
Produção (Acesso Público a sign-up
):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPublicInvokeForSignUp",
"Effect": "Allow",
"Principal": "*",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:sign-up"
}
]
}
Desenvolvimento (Negar acesso a dev_protect
funções sem developer
tag):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonDeveloperAccessToDevProtected",
"Effect": "Deny",
"Principal": "*",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/dev_protect": "true"
},
"ForAnyValue:StringNotEqualsIfExists": {
"aws:PrincipalTag/developer": "true"
}
}
}
]
}
Essa é uma boa abordagem ou existem outras melhores para o meu problema?
A melhor abordagem é usar o API Gateway e colocar os lambdas atrás de rotas específicas (imagino que você esteja usando as URLs de invocação direta de lambdas no momento?). Permita que o lambda seja invocado pelas credenciais do IAM do API Gateway (não do chamador).
Então você pode colocar uma política de acesso na frente das várias rotas. Então rotas prod têm todas allow all, e rotas dev você pode permitir por IP, valor de cabeçalho, etc. Como o bloqueio acontece na frente do APIG, você não será cobrado https://stackoverflow.com/a/74674307/5746996