[AWSKRUG] 3월 28일 (목) - 보안 소모임 후기

Contents: AWS 환경에서의 보안의 기본인 Credential 과 API Key 관리에 대한 사례를 공유하여 보안성을 고도화 할 수 있는 방안을 공유

 

내 직무와 엄청 핏하진 않고 일정이 겹쳐서 갈까말까 수십번은 고민했던 밋업

 

그런데, 마침 팀에서 필요로 하던 주제라 팀장이 등을 밀어줘서 참석하게 됐다.

 

사용하는 외부 서비스가 늘어나면서 API key와 credential이 계속 늘어나고 있어서 조금씩 문제가 눈에 띄기 시작했다.

 

대충 정리해도, AWS, elastic cloud, open AI, hyvortalk, sendgrid, froala, twilio 등 프로필 별로도 나뉘다보니 점점 api key와 credential 코드가 쌓이고 있었다.

 

이 문제에 대한 나름의 해결책을 기대하고 들으러 왔다.

 

올해 변경된 스티커라고 한다

 

어... 그런데 일단 발표 시간이 너무 짧았다.

 

한시간+ 짜리 발표를 25분에 압축하려니 발표자 분도 발표하면서 급해보였고

 

듣는사람들도 물음표가 많이 붙었을 것 같다..(안그럴 수도 있는데 나는 그랬다)

 

발표의 큰 맥락이 느껴지지 않았다고 할까? 

 

내가 이해한대로 발표를 요약하자면 아래와 같다.

 

1. 크레덴셜의 정의

id/password, api key, personal, ssl/tls, data encryption

 

2. 온프레미스환경에서 AWS과 같은 클라우드로 인프라 환경이 넘어오면서 사용자 인증을 위한 api key나 크레덴셜 관리가 더 중요해졌다. 

 

3. 보편적으로 사용되던 IAM 유저를 생성하는 방식은 더이상 권장하지 않음. api key가 무조건 로컬에 관리 저장되야하기 때문이다.

 

4. 권장되는 몇 가지 방법들이 있음. Identity Center, ec2 내부에서 assume 설정(정확히 들은건지 모름) 등의 방법을 권장한다.

 

5. 외부에서 연동할 때는 iam provider를 이용한 oidc 프로토콜을 사용하자.

온프레미스의 경우에는 IAM Roles Anywherer에서 Trust anchor를 사용

 

6. AWS 키 패턴은 분석은 솔직히 왜 들어갔는지 잘 모르겠음.

이게 노출되서 account number를 알게되서 어떤 문제가 있을지에 대한 설명은 해주시지 않았음.

 

7. KMS vs Secret Manager

KMS : 암복호화 데이터 보호, 안전하고 확장가능한 키관리, AWS 서비스와의 연동, 쉬운 키변경, 키를 N개 만들 수 있음

 

Secret Manager : 시크릿(크레덴셜)을 저장 관리, 시크릿 관리, 안전하게 저장하고 관리하는 시크릿, 자동 변환, 연동, 관리와 모니터링

 

8. Secret Manager Use Cases

너무 급하게 마무리되서 못 따라갔음

람다를 이용해서 시크릿 매니저를 갱신하는 패턴을 많이 씀. 시크릿 매니저 자체에서도 로테이션하는 람다를 지원함

---

내가 기대했던 내용과는 다른 방향의 발표 방식이었지만, 몇 가지 키워드는 얻을 수 있었다.

 

일단은 내 환경에서는 Secret Manager를 써야하는 상황인 것 같다.

 

그리고, 현재 우리도 AWS 계정을 IAM 역할을 지정해서 쓰고 있는데, 보안 위험이 있긴한 것 같다.

(사용자가 몇명 안되서 엄격하게 관리할 필요가 있을까 싶기도 함)

 

대부분의 기업에서 이러다가 보안문제가 생기는거겠지만 말이다.

 

발표자 분의 내공은 발표하는 중간중간에 느껴졌지만 발표 시간을 너무 적게 준 것 같아 아쉬웠다.

 

왜 아이스브레이킹 시간과 발표시간이 비슷했어야 했을까?

 

발표자료라도 다시 볼 수 있었으면 좋겠다.