작성
·
193
답변 2
3
안녕하세요. 정확한 말씀입니다.
보안성이 중요하지 않은 정보에 대한 GET Method라면 API Key가 클라이언트에게 노출되는 경우가 있습니다. 예를 들어 비로그인 사용자에게 백엔드에서 받아오는 동적 컨테츠를 보여줘야 한다거나, 구글 맵 API같이 클라이언트 앱마다 Key를 지정하여 접속을 허가하거나 사용량을 관리해야 하는 경우가 있겠지요.
하지만 중요정보의 Get 그리고 그 외의 모든 API 요청에 대해 모든 클라이언트가 단일 Key를 사용한다는 것은 말씀하신것처럼 보안측면에서 현실적이지 않습니다. 그래서 강의초반에 칸반보드에 로그인 기능을 구현하고 토큰을 발행한다거나 하는 내용을 다루어야 할지 고민이였는데 아무래도 AWS서비스 설명 대비 프론트/백엔드 프로그래밍 비중이 점점 커지는 것 같아 다루지는 못했습니다.
다만 말씀해주신 내용을 듣고 다시 생각해보니, 하다못해 강의 후반에 CloudFront URL을 생성하고 람다 함수마다 CORS - Access-Control-Allow-Origin에 해당 URL를 명시해주고, 다루지 못한 내용에 대해서는 간략하게나마 말씀을 드렸다면 좀 더 흐름이 매끄러웠을텐데하는 아쉬움이 남습니다. 강의 리뉴얼을 하게 된다면 말씀하신 내용을 감안하도록 하겠습니다.
참고로 API Gateway에서는 Lambda 또는 Cognito 서비스로 접속제어를 하는 방법이 있습니다. 추후에 관심이 있으시다면 아래 링크를 참고해주시면 좋겠습니다.
제가 업무상 최근 진행했던 프로젝트들에서는 싱글 사인온(SSO)이라면 SAML, OAuth를 사용하고, 모든게 다 커스텀이라면 개별 사용자마다 램덤키(Salt)를 DB에 저장한 후, 사용자 인증이 되면 Salt와 Private Key를 섞고, 토큰 만료시간을 담아 JWT를 생성 후 클라이언트에 발행하고, API요청시마다 해당 토큰을 첨부하도록 하여 해당 사용자로부터 온 요청이 정말 맞는지, 요청에 접근권한이 있는지, 키가 만료는 안되었는지 등을 보고 인가하는 방식을 쓰고 있습니다.
API 접근제어에 대한 방법론은 다양하기도 하고 꾸준히 발전하고 있습니다. AWS 상에서 모든 것을 구현한다면 Amazon Cognito나 AWS Single Sign-on 서비스로 구현하면 될 것인데 이후 강좌에서 기회가 된다면 다루어 보도록 하겠습니다.
좋은 코멘트 남겨주셔서 다시 한번 감사드립니다.
0