API Gateway로 요청을 보낼 때 Api key를 헤더에 담아 보내는 것으로 보안을 해결했고 헤더는 다 노출이 되고 심지어 API key는 사용량 조절을 위해 주로 쓰이고 보안적으로 쓰지않는 것을 권유하고있다. 그래서 이왕하는거 나는 진짜 한번 제대로 구성해보자 라는 마음으로 세팅을 했다.
우선 권한 부여자 워크플로우부터 보여주겠다.

먼저 클라이언트에서 API Gateway로 요청을 보내면 Auth function이 실행되며 allow / deny 을 돌려준다. 만약 allow면 원래 API gate way로 트리거가 엮여있던 람다가 정상적으로 실행되고 deny이면 403번을 뜨면서 에러가 뜬다. 또한 그 외는 500에러가 뜬다.
권한부여자 세팅은 간단한데 먼저 lambda를 하나 생성해주고 API Gateway로 가 권한부여자설정을 해주고 리소스로가 매소드 요청에서 승인에서 해당 람다를 골라주고 배포하면 끝이다.
나는 Auth Lambda를 JWT를 통해 검증하게 하였고 코드는 아래와 같다.
"use strict";
const jwt = require('jsonwebtoken');
const splitByDelimiter = (data, delim) => {
const pos = data ? data.indexOf(delim) : -1;
return pos > 0 ? [data.substr(0, pos), data.substr(pos + 1)] : ["", ""];
};
module.exports.lambdaHandler = async (event) => {
const [type, token] = splitByDelimiter(event.authorizationToken, " ");
const allow = type === "Bearer" && !!jwt.verify(token, process.env.JWT_SECRET);
const policy = {
principalId: "*",
policyDocument: {
Version: "2012-10-17",
Statement: [
{
Action: "execute-api:Invoke",
Effect: allow ? "Allow" : "Deny",
Resource: "*",
},
],
},
};
return policy;
};
이것으로 이제 보안은 빵빵해졌지만 이메일인증, 휴대폰인증등을 람다로 뺀 이유가 본 서버의 부하를 피하기위해 뺀거인데 토큰까지 들어가고 복잡해진 기분이 들긴하지만 토큰말고 고정값을 넣어 그 고정값을 헤더로 넣어보내면 Allow를 뜨게 할 수 는 있지만 그거는 또 별로인거 같았다.
서버도 c4.xlarge로 업그레이드 한 상황이고 현 시점에선 포토폴리오용으로 채우기 위한게 사실 99퍼이기때문에 최대한 안전하게 짜봤다.
'TIL' 카테고리의 다른 글
| Auto Scaling, Capacity Provider, Discord WebHook (1) | 2023.02.13 |
|---|---|
| Grafana (0) | 2023.02.11 |
| AWS API Gateway 권한 (0) | 2023.01.29 |
| Simple & Easy Notification Service + AWS lambda (0) | 2023.01.22 |
| PresignedURL S3 - Lambda image Resizing (0) | 2023.01.15 |