프로젝트 경험 소개 : 플랫폼 키 관리 게이트웨이 개발

배경

요즘 여러 서비스들에서 보안 문제가 많이 터진다.

우리 팀도 경각심을 느껴 점검했고 많은 개선 사항을 발견했다.

급하게 달리는 회사들은 놓치는 부분이 있을 수밖에 없는 것 같다.

그중 가장 큰 작업은 플랫폼 키 관리 방법 개선과 접근 통로 제한이었다.

그 방향에 대한 내 아이디어가 잘 먹혔고, 리딩할 수 있는 기회를 얻었다.

 

위험 요소  

우리 팀은 IoT 서비스를 운영한다.

기기 제어와 상태 처리를 플랫폼에 맡겨 서비스 개발에 집중하는 것이다.

그 플랫폼에 인증할 수 있는 키와 접근 경로 관리를 위험 요소로 판단하였다.

 

1. 키 분산

플랫폼 접근 키가 여러 환경에 분산되어 있었던 것을 큰 문제로 삼았다.

단순히 클라우드 제공사나 가상머신이 분산된 경우도 있고, 키를 저장하는 방법도 다양했다.

환경 중 하나라도 문제가 생기면 키가 노출되기 십상이었다.

 

2. 동일 권한

서비스마다 필요한 플랫폼 기능이 다르다. 그럼에도 단일 권한의 플랫폼 키로 관리하고 있었다.

위험 정도에 따라 키 관리 우선순위가 결정되었으면 했다.

기존에는 어떤 키가 노출되어도 모든 서비스를 아우르는 권한의 키가 탈취됐다.

 

3. 정적 키

예방만큼이나 빠른 대응도 중요하다.

플랫폼 자체 키를 바꾸는 일은 쉽지 않았고,

위험을 인지해도 빠르게 키를 변경하거나 노출된 키를 제한할 수 있는 명확한 대응 규칙이 없었다.

 

플랫폼 키 관리 게이트웨이

플랫폼과 서비스 사이에 레이어를 한층 더 쌓았다.

서비스들은 이제 직접 플랫폼에 요청하지 않고, 키 관리 게이트웨이에 요청을 전달한다.

게이트웨이에선 요청을 검증하고, 플랫폼으로 전달하게 된다.

각 서비스들이 플랫폼을 직접 접근할 수 있는 경우를 모두 제거한 것이다.

 

1. 중앙화

플랫폼 키를 통일된 방식으로 관리할 수 있게 되었다.

키 관리 게이트웨이, 암복호화를 위한 서비스 외에는 플랫폼 키를 확인할 수 있는 IAM 권한이 없다.

각 외부 서비스들은 게이트웨이에서 생성한 단기 인증 키를 사용한다.

또 플랫폼의 접근 통로를 최소화할 수 있었다.

게이트웨이가 사용하는 NAT IP만을 허용하여, 그 외에서는 어디서도 직접 API를 호출하거나 이벤트를 수신할 수 없다.

 

2. 권한 분리

서비스마다 필요한 권한에 맞는 키를 발급하고, 사용 시에는 키 관리 게이트웨이에서 확인한다.

혹 키가 탈취되어도 전체가 아닌 일부 권한으로 영향 범위를 줄일 수 있다.

예를 들어 기기 조회가 가능한 것과 제어까지도 가능한 것은 우리 회사 서비스에선 천지 차이였다.

 

3. 동적 키

만약 자체 키가 탈취당한다면, 키 저장소에서 키 값을 교체하는 것으로 대응할 수 있다.

레디스에 비허용 IP와 키를 관리하여 탈취당한 키나 토큰, 블랙리스트로부터의 추가 접근을 막을 수 있다.

 

4. 관리 주체 이전

기존에는 키 보관소, 서비스가 배포되는 가상머신 관리 주체가 서버 팀원이었다.

이번 키 관리 게이트웨이를 포함한 키 보관소, 인증 서비스의 보안 레이어는 개발자가 운영체제를 직접 다루지 않는다.

모든 서비스를 Lambda, Fargate 등 AWS에서 추상화한 완전 관리형 서비스를 사용한다.

이때 애플리케이션에서 발생하는 로그를 꼼꼼히 마스킹해야 한다.

결국 애플리케이션에서는 키를 사용해야 하고, 그 로그가 원본으로 남으면 로그 탈취가 곧 키 탈취로 이어지기 때문이다.

 

5. 테스트

크게 세 가지를 테스트했다.

- 기존 요청, 응답 포맷과 동일하게 동작하는가 : 테스트 코드와 개발 환경에서의 QA로 확인했다.

- 부하를 감당할 수 있는가 : 피크 타임의 요청 수를 가상 유저, N분간 동시 요청을 수행했다.

- 중단은 없는가 : 적은 수의 가상 유저로 N시간 동안 꾸준히 요청을 반복했다.

그 밖에 IP 화이트리스트, 인증되지 않은 토큰 값, 로그 마스킹, 권한 검증 등의 동작을 검증했다.

어쩔 수 없이 기존 플랫폼을 직접 요청할 때보다 약간의 지연은 발생했지만, 사용자에게 유의미하지 않은 지연이었고,

그에 대비하여 얻을 수 있는 보안 이점이 크다고 판단하여 전환을 결정할 수 있었다. 

 

 

빠른 전환을 위한 고민

플랫폼을 직접 호출하던 꼴에서, 중간 플랫폼 키를 관리하는 게이트웨이에 전달해야 한다.

그렇기 위해, 기존에 플랫폼을 직접 사용하던 모든 서비스의 API 호출 URL을 변경해야 했다.

사용자에게 배포를 공지했지만, 그럼에도 피해를 최소화하기 위한 빠른 전환과 롤백을 고민해야 했다.

Lambda와 Spring boot를 주로 사용하고 있고, 서비스 특성마다 빠른 전환을 위한 전략이 달랐다.

 

1. Lambda의 환경 변수 변경

Lambda가 트리거에 의해 매번 실행된다는 이유로 단순히 설정 서버의 값만 바꾸면 된다고 생각해선 안된다.

AWS Lambda에는 실행 컨텍스트 영역이 있다.

우리 팀은 플랫폼 url이나 키 값 등, 재사용하는 값을 실행 컨텍스트에 올려, Warm start 상황에서 마치 캐시처럼 사용한다.

팀에서 찾은 가장 편한 꼼수는 구성 값으로 버전 혹은 마지막 배포일을 추가하고 그 값을 바꿔주는 것이다.

호출 주기와 상관없이, 구성 값이 변경되면 실행 컨텍스트를 남기지 않고 새로 실행됨을 이용한다.

 

2. 스프링 부트의 RefreshScope

스프링 부트에선 @RefreshScope를 사용하면, 동적으로 빈을 재생성할 수 있다.

예를 들어 Config 서버에서 설정 값을 바꿔주고, Actuator api 콜이면 동적으로 설정 값과 관련 빈을 교체할 수 있다.

변경되는 설정 값을 플랫폼의 설정 값들로 하여, 배포 없이 플랫폼 엔드포인트를 변경할 수 있었다.

특히 여러 서비스에서 동시에 값을 변경해야 할 때 유리하겠다. 

 

3. Blue-Green

팀에서는 @RefreshScope를 우선으로 검토했지만, 서비스 별로 사용할 수 없는 경우도 있었다.

서비스 중에는 동적 Config 서버를 사용하지 않는 경우도 있고,

설정 값을 사용하는 빈이 너무 깊고 복잡하여 재생성의 범위를 찾는 것이 까다로운 경우도 있었다. 

이 경우 새로운 버전의 Service는 한 부 더 만들어두고, 전면에 LB에서 라우팅 규칙을 변경하는 꼴로 배포했다.

@RefreshScope 보다 확실하지만, 더 많은 리소스가 필요했고 LB의 규칙을 변경해야 하는 관리가 필요했다.

대신 롤백은 설정 값을 다시 바꿔야 하는 @RefreshScope 보다 이미 이전 버전이 준비된 블루-그린이 더 빨랐다고 평가한다.

 

정리

이슈 : 

  - 코어 플랫폼 키가 서비스, 배포 환경 별로 분산되어 키 관리와 접근 제한에 어려움

  - 서비스 별로 동일 키를 갖고 있어, 권한 분리, 노출 시 접근 제한 불가

작업 :

  - 서비스와 플랫폼 사이에 중앙 키 관리 게이트웨이 개발

  - 담기 임시 토큰 발행, 서비스 별 다른 플랫폼 사용 권한 관리

  - IP, 토큰 사용 제한

  - 플랫폼 키 보관 중앙화, AWS 완전 관리형 서비스 전환

결과 : 

  - 플랫폼 키 저장 환경 단일화, 분산 제거

  - 플랫폼 접근 제한 강화 / 게이트웨이에서만 접근 가능하도록

  - 서비스 키 별 권한 분리

  - 키 노출 시 사용 제한, 키 교체 용이