8월은 정말 바빴다. 대규모 MSA 전환 프로젝트 이후 처음으로 ISMS 심사를 앞두고 있어서 마음 한 켠은 늘 긴장 상태였다.
내가 맡고 있는 부분은 내부 고객이 사용하는 관리 도구(Back Office)의 인증(Authentication) 및 인가(Authorization)와 공통 라이브러리를 개발하는 것이다. 비용 문제로 API 게이트웨이가 없어서 istio proxy로 메시업을 하고, 다른 서비스에서 인증과 인가 서버를 위해 내 애플리케이션을 통해 API 호출 및 서비스에 접근하는 형태로 동작하게 되었다.
처음에는 화면단 인가 처리만 하던 부분에 대해 API 단에서도 인가 처리를 도입하는 작업을 시작했다. 그리고 현재 인가처리는 Redis 인메모리 디비를 세션 서버로 사용하고 있어서, 사용자가 인증(로그인)할 때 Security Context 정보를 역직렬화하여 저장하고 페이지와 API에 대한 접근시 Redis Authorization Interceptor를 통해 모든 요청을 검증하도록 만들었다.
처음에는 레디스 인터셉터를 통해서 모든 리퀘스트를 등록했는데, 서버가 각각 다르기 때문에 공통 라이브러리에 수정 사항을 각각의 영역 개발자에게 공지하고 예외 패턴을 추가하고, 가이드라인을 작성하여 배포했다.
이때 느낀 점은 개발하는 것보다도 각 담당자들에게 어떻게 적용하고 어떤 식으로 동작 하는 지 설명하는 부분이 꽤 어려웠다. 또한, 모든 개발자들의 우선 순위가 다르기 때문에 인터셉터를 만들어 두었지만 실제로 ISMS 심사 전에 적용된 영역이 제한적이라 많이 애를 먹었다. 이 경험을 통해 다수의 사람을 리딩이라는 것이 얼마나 어려운 일인지 알게 되었고, 소프트 스킬의 중요성도 크게 깨닫게 되었다.
8월 예비 심사 전에 ISMS의 중요성을 팀장님께 어필했는데, 보안 파트를 지원하는 것이라는 피드백을 통해 대수롭지 않게 넘어가서 더 많은 준비를 못해 아쉬웠다. 하지만 몇몇 개발자들은 중요성을 깨달아주고 협력해주고 있어서 작업이 수월하게 진행되고 있다.
현재는 9월 중순에 있을 본 심사에 앞서 추가적인 ISMS 지적 사항으로 기존에 AOP를 통해 내부 고객 로그만 저장하던 부분에서 내부 고객이 아닌 외부 고객의 정보를 취급할 때 어떤 정보에 접근했는지 로그를 남겨야 한다는 이슈를 받았다. 모든 영역에서 개인정보를 다루지 않기 때문에 모든 영역에 또 다른 AOP 로그를 남기기는 어려웠다. 그래서 기존 공통 라이브러리의 엔티티에 속성을 추가하여 개인정보보호법 2조 항목들을 로그로 저장하도록 하는 새로운 API를 개발하였다.
아직은 2년차이지만, 사수나 부사수 없이 인증 및 인가와 관련된 다양한 프로세스를 혼자서 직접 개발하고 가이드라인을 만들어 배포하면서 보안에 대한 준비 자세가 얼마나 중요한지 깨달았다.
결함을 미리 대비하고 처리하는 것이 중요하다는 생각이 들었다. 아직도 배울 점이 많기 때문에 이 경험을 통해 사람들과 소통하며 더 나은 개발자로 성장하고자 한다.
9월 중순에 본 심사가 다가오면서 다른 동료들을 격려하며, 내가 할 수 있는 일을 열심히 해보려고 한다. 아자 아자 화이팅!!