원격 개발 기능을 통해 텔레그램 채팅만으로 프로젝트를 수정할 수 있게 되었다. 개발 세션에서 코드를 고치고, 브랜치에 커밋하고, 원본 저장소에 통합한 뒤 서비스 재시작까지 가능하다. 수정할 수 있는 프로젝트에는 이 에이전트 봇 자체도 포함된다. 편리하긴 한데, 이 구조가 보안 강화 없이 그대로 적용되면 텔레그램 계정이 탈취되었을 때 서버에 악성 코드를 심는 부분이 너무 취약해진다. 추가적인 보안 강화가 필요했고, 그 수단으로 시놀로지 SSO Server를 이용하기로 했다.
여지 없이 걸고 넘어지는 보안 이슈
여기에서 문제는 저장소에 통합 및 서비스 재시작이 가능하다는 점이다. 이 머신의 로컬 오케스트레이터 역할을 하는 에이전트 봇 서비스가 변경될 수 있다는 것이다. 개발 세션에서 코드를 고치는 것까진 괜찮다. 어차피 격리된 워크스페이스 안에서 일어나는 일이니까. 하지만 그 수정 사항이 메인 저장소에 통합되고 서비스가 재시작되는 순간 이야기가 달라진다.
텔레그램 계정이 탈취된 상태에서 챗봇을 통해 이 에이전트 봇에 기능이나 권한을 추가하고 서비스를 재시작해 버리면 머신에 있는 민감한 정보가 노출될 수 있다. 환경 변수에 저장된 API 키, 시놀로지 나스 접근 정보, 다른 서비스들의 인증 토큰까지. 악성 코드가 삽입될 수도 있고.
2차 인증을 통해 보안 강화하기
일단 개발 세션과 브랜치 커밋은 자유롭게 두되, 메인 저장소에 통합하거나 서비스를 재시작하는 동작에만 2차 인증을 걸기로 했다.
메일을 통한 2차 인증하기
처음 생각했던 방식은 에이전트 봇이 내 이메일로 인증 링크를 보내고, 내가 그 링크를 눌러 인증을 완료하는 흐름이었다. 실제로 코덱스가 관련 코드를 구현해 줬고 환경 설정만 하면 되었는데, SMTP 설정에다 발송 전용 이메일 계정까지 만들어야 했다. 이 계정의 아이디와 비밀번호를 어딘가에 보관해야 한다는 점이 마음에 걸렸다.
발송용 이메일 비밀번호를 환경 변수든 파일이든 따로 보관해야 한다는 것 자체가 깔끔하지 않았다. 보안을 강화하려고 붙이는 건데, 그 수단이 비밀번호 하나를 새로 만들어내는 셈이다. 별도 계정을 하나 만들어 쓰면 되긴 했지만, 무엇이든 비밀번호를 추가로 관리해야 하는 구조가 세련되지 못하다고 느꼈다.
SSO Server를 이용하기
고민하다가 떠올린 게 시놀로지 나스에 있는 SSO Server를 이용하는 방법이다. 시놀로지 계정으로 인증하면 그 인증 정보를 2차 인증 수단으로 활용하는 구조다. 시놀로지 나스가 기본 패키지로 이 앱을 제공하기 때문에 별도 설치 없이 바로 쓸 수 있다. 이미 쓰고 있는 시놀로지 계정이 곧 인증 수단이니 비밀번호를 따로 보관할 필요도 없다.
비록 동일 네트워크 안의 머신들이지만, 물리적으로 독립된 다른 장비에서 제공하는 인증 정보를 쓰기 때문에 보안 관점에서 충분히 의미가 있다. 에이전트 봇이 돌아가는 서버가 뚫려도 나스까지 동시에 뚫리지 않는 한 2차 인증은 살아 있으니까. 시놀로지 나스의 값은 기계값이 아니고 소프트웨어 값이라더니, 은근히 이런 곳에서 빛을 발한다.
SSO Server를 활성화하고 응용 프로그램을 추가하여 ID와 시크릿 발급받기
위에서처럼 SSO Server에서 응용 프로그램을 하나 추가하면 클라이언트 ID와 시크릿이 발급된다. 이걸 에이전트 봇에 설정하면 SSO를 이용한 2차 인증을 바로 사용할 수 있다.
SSO Server 인증을 통과해야 메인 저장소 통합과 서비스 재시작 가능
악성 코드가 포함된 내용이 메인 저장소로 통합되고 서비스가 재시작되면 그야말로 모든 보안 수단이 무력해질 수 있다. 그래서 통합과 재시작은 아주 보수적으로 접근해야 하고, 이 위험한 작업을 진행하기 전에 2차 인증을 해야 한다. 메인 저장소 통합이나 서비스 재시작을 요청하면 SSO 인증 페이지로 리다이렉트되고, 시놀로지 계정으로 로그인해야만 작업이 진행되는 흐름이다.
물론 이 수단이 포함된 코드 자체가 악성 코드에 의해 무력화되는 시나리오까지 완전히 막을 수는 없다. 하지만 적어도 텔레그램이 탈취된 상태에서 서버를 오염시키는 첫 번째 관문을 하나 세울 수 있다는 데에는 의의가 있다. 2차 인증을 뚫지 못하면 민감한 수정사항들은 개발 세션 워크스페이스에 한정되니까.
SSO Server를 통한 인증은 성공적, 개발 세션 수정 내용 통합은 글쎄
에이전트의 도움을 받아 SSO Server 셋팅을 하고, 개발 세션의 수정 내용을 메인 저장소에 통합한 뒤 서비스 재시작까지 적용했다. 잘 동작하는 것을 보니 기분이 좋다. SSO 2차 인증은 다른 보안에 민감한 사항을 다룰 때 추가로 사용할 수 있을 것 같다.
개발 세션 수정 내용을 저장소에 통합하고 서비스를 재시작하는 부분은 일단 한 번 해보니 보안 외에도 여러 리스크가 있었다. 개발 세션에서 수정한 내용에 대해 실제 테스트를 해보지 못하고 통합하다 보니 잘 되는 기능들이 망가지기도 하고, 심하게는 서비스 자체가 블로킹되어 직접 서버에 붙어서 수동으로 롤백해야 했다. 아무리 에이전트가 테스트 코드를 만들어서 회귀 테스트를 해도 실제 환경에서 일어나는 사이드 이펙트까지는 잡아내지 못했다.
좀 더 나은 개발 환경이 필요하다
SSO 인증을 통한 2차 인증은 퍽 만족스러웠지만 개발 세션에서 수정한 내용을 바로 통합하고 적용하는 부분은 많이 거칠다. 실제 테스트가 가능하고, 개발 세션의 제한된 에이전트 권한보다 더 넓은 권한을 가진 머신의 에이전트와 대화하며 개발하는 게 훨씬 낫다. 즉, 내가 서버에서 직접 붙어서 에이전트를 통해 개발하는 환경 그대로 텔레그램 채팅에서 할 수 있어야 한다.
고민하던 중 에이전트가 가상 머신이라는 솔루션을 제시했다. 서버 머신은 호스트가 되고 이 머신 안에서 동일한 환경으로 구성된 가상 머신을 띄우는 것이다. 개발 세션은 이 가상 머신 환경 안에서 수정하고 적용한다. 설사 수정된 내용이 문제를 일으키더라도 호스트에서의 서비스가 망가지는 것이 아니기 때문에 부담이 없다. 가상 머신이라는 별개의 환경이기 때문에 실제와 동일한 테스트도 가능하고, 검증이 끝난 것만 호스트에 반영하면 된다.
꽤 괜찮은 솔루션이다. 다음은 가상 머신을 이용해 이 에이전트 봇을 텔레그램 채팅을 통해 완벽하게 추가 개발할 수 있는 환경으로 만들어 보려고 한다.