JEA를 사용해 안전한 테스트 환경 구축하기(feat. Hyper-V) (작성중)
1년 만의 포스팅입니다. 많은 일이 있었군요.
AI의 발전은 무섭습니다. 42 과정에 다닐 때만 해도 Hype이라 생각하고 무시하려 했지만, 이제는 AI를 활용하지 못하면 살아남지 못할 것 같습니다. 지금이라도 AI를 활용하려는 여러 시도를 하고 있습니다. << 이사람 자퇴 왜함?
아무튼, 개인 프로젝트를 진행하다 안전한 AI 에이전트 환경 구축이 필요하게 되어 여러 가지 삽질한 내용을 정리합니다.
아, 여기서 Safe는 Cyber Security보다는 Resilliance에 더 가깝습니다.
# 1. 동기
최근에 토큰 녹일 겸 + 일하기 싫어서 백신 개발 프로젝트를 시작했습니다. 거창한 건 아니고요, 핵심적인 기능만 간단하게 구현하면서 공부해 보려고 합니다.
그런데 사람마다 '간단한'이란 단어를 다르게 정의하더군요. 작년의 저라면 이런 대규모 프로젝트를 시작조차 못 했을 텐데 코덱스의 도움을 받아 진짜 작동하는 백신을 개발해 보고 싶어 졌습니다.
백신, 특히 EDR이라면 커널 영역에서 작업해야 합니다. 선제적으로 프로세스의 행위를 수집하고 분석하려면 유저랜드에서는 불가능합니다.
커널 모드에서 작동하는 드라이버를, 윈도우에서 개발해야 한다니 벌써 어지럽죠? 하지만 코형과 함께라면 불가능한건 없습니다.
사실 코드리뷰에 그만큼 시간을 쓰긴 하는데, 일단 작동하는데 뭐 어떻습니까. 개인 프로젝트면 그걸로 충분하죠.
일단 만들어. 그리고 부숴. 퇴근하고 오버워치나 하러 가야겠습니다.
딴 길로 샜군요. 앞으로는 진중하게 쓰겠습니다.
AI의 시대가 됐어도 여전히 (그리고 희망컨데 앞으로도) 만들고 테스트하고 다시 만드는 과정의 연속입니다. 커널 드라이버도 다르지 않습니다. WinDBG MCP도 있는 세상에서 디버깅 환경 구축은 눈 깜빡할 사이에 끝납니다. 청휘석 사는 데 돈을 다 썼기 때문에 실제 머신은 없고 VM 상에서 테스트하고 있습니다. 생각해 봤는데 돈이 있어도 일단 VM에서 테스트하겠군요.
그런데 저는 Hyper-V를 사용합니다. 아시다시피 Hyper-V는 Windows 내장 기능을 적극 활용하는 Type 1 하이퍼바이저입니다. 빌트인 그룹도 있죠. S-1-5-32-578. VBoxManage.exe를 실행하면 되는 VirtualBox랑은 다르게 Hyper-V 인스턴스를 제어하려면 저 그룹에 들어가 있어야 합니다.
이 글을 찾으신 분들은 비슷한 상황에 있을 거라 생각합니다.
CodexOfflineUser를 S-1-5-32-578에 추가할 생각은 아니었겠죠?
설마요.
아, 큰일났습니다.
저는 Full AI SLOP으로 스파게티 코드를 만든 다음에 프론트엔드만 예쁘게 꾸며서 자랑하려고 했는데, 개발 환경 구축에서 막혀 버렸군요.
Elevate된 권한으로 시작하는 Scheduled Task를 생성하고, ACL에 코덱스를 추가해야 하나? 너무 더러운데? 하고 있던 저에게 코형, 아니 코쌤이 개쩌는 대안을 제시했습니다.
# 2. JEA
Just Enough Administration.
이름부터 이 Usecase에 적합해 보이지 않나요?
WinRM이라고는 쉘 발사대로 알고 있던 저에게 코쌤이 공식 문서를 들이밀었습니다.
AI에게 RTFM을 당하다니.
기왕 RTFM 당한김에, JEA 설명도 AI에게 부탁해야겠습니다.
JEA, Just Enough Administration은 PowerShell의 Role-Based Administration 기술입니다.
이름 그대로 관리자 권한을 통째로 던져주는 대신, 필요한 관리 작업만 수행할 수 있는 제한된 환경을 만들어 줍니다.
제가 원한 것도 정확히 이거였습니다.
CodexOfflineUser에게 Hyper-V 관리자 권한을 주고 싶은 게 아닙니다.
제가 원하는 건 기껏해야
VM 시작하고
VM 끄고
체크포인트 만들고
필요하면 상태 좀 확인하고
정도입니다.
그런데 Hyper-V를 제어하기 위해 계정을 Hyper-V Administrators에 넣어버리면 이야기가 달라집니다.
"VM 몇 개 조작해도 됨"이 아니라 "자 여기 Hyper-V 관리 권한"이 되어버립니다.
AI 에이전트한테요.
똑똑해진 건 알겠는데 아직 거기까지 신뢰하진 않습니다.
특히 프롬프트 하나 잘못 읽고 제가 밤새 만든 VM을 시원하게 밀어버리는 미래는 별로 보고 싶지 않습니다.
그렇다면 중간에 뭔가를 하나 두면 됩니다.
Codex
|
| WinRM / PowerShell Remoting
v
JEA Endpoint
|
| "이것만 하세요"
v
Hyper-V
CodexOfflineUser는 JEA Endpoint에 접속할 권한만 가집니다.
그리고 그 Endpoint에서는 제가 허용한 명령만 보입니다.
Get-VM은 된다.
Start-VM도 된다.
Stop-VM도 필요하겠죠.
그런데 갑자기 AI가 무슨 바람이 불어서 Remove-VM을 실행하려고 한다?
그런 명령은 애초에 세션에 노출하지 않으면 됩니다.
조금 더 세밀하게 들어가면 특정 Cmdlet만 허용하는 것을 넘어, 허용할 함수나 외부 프로그램 등을 제한하고 Cmdlet의 파라미터에도 제약을 걸 수 있습니다.
즉 "PowerShell을 실행할 수 있다"와 "PowerShell에서 내가 허용한 작업만 할 수 있다"를 분리할 수 있습니다.
여기까지는 좋습니다.
그런데 한 가지 문제가 있습니다.
CodexOfflineUser는 Hyper-V Administrators가 아닙니다.
그럼 Start-VM을 보여줘 봤자 실행할 권한이 없지 않나요?
맞습니다.
그래서 JEA에는 Virtual Account라는 아주 수상하고 아름다운 물건이 있습니다.
사용자는 자기 계정으로 JEA Endpoint에 접속하지만, 실제 명령은 세션에 할당된 일회성 로컬 가상 계정의 권한으로 실행할 수 있습니다. 멤버 서버에서 JEA의 Virtual Account는 기본적으로 로컬 Administrators 권한을 사용할 수 있고, 필요하다면 어떤 로컬 그룹의 권한을 사용할지도 구성할 수 있습니다.
덕분에 구조가 이렇게 됩니다.
CodexOfflineUser
|
| 인증
v
+-----------------------+
| JEA Endpoint |
| |
| Get-VM O |
| Start-VM O |
| Stop-VM O |
| Remove-VM X |
| ... |
+-----------+-----------+
|
| Virtual Account
v
Hyper-V
이제 좀 마음에 듭니다.
AI에게 관리자 권한을 주지 않았습니다.
관리자 권한이 필요한 작업을 수행할 아주 좁은 창구만 하나 열어줬습니다.
게다가 이 창구로 들어오면 사용할 수 있는 명령도 제가 정합니다.
제가 원했던 "Safe"와 상당히 비슷해 보입니다.
물론 여기서 Safe는 다시 한번 말하지만,
"AI가 해킹당해도 절대 안전합니다!"
같은 거창한 이야기는 아닙니다.
제가 원하는 건 AI가 실수하거나, 이상한 판단을 하거나, 제가 프롬프트를 잘못 작성했을 때의 blast radius를 줄이는 것입니다.
AI한테
"이 VM 재부팅하고 테스트해줘."
라고 시켰는데 갑자기 호스트까지 창의적으로 정리하기 시작하면 곤란하잖아요.
그러니 능력 자체를 줄여버립시다.
Prompt로 "절대 다른 VM 건들지 마!"라고 열 번 쓰는 것보다 OS가 "응 그 명령 없음"이라고 하는 편이 저는 조금 더 마음이 편합니다.
무섭습니다. 이제 도입부만 쓰면 대충 제 심리를 파악해서 글도 써주는군요. 정확해서 더 무섭습니다.
이러다가 1일 5포스팅이 가능해 버릴지도 모릅니다.
뭐, 조금만 정정?하면 Remove-VM보다는 언어폭력에 지친 에이전트가 Sandbox를 탈출하는 시나리오가 더 무섭긴 합니다.
갑자기 65535개의 VM 인스턴스를 생성하고, 루트 디렉토리를 마운트한 다음에 Remove-Item -Force를 돌릴 지도 모르니까요.
흠 앞으로 에이전트를 친절하게 대해야겠군요. 스카이넷이 얼마 남지 않았습니다.
젠장할. 갑자기 글을 쓰기 귀찮아졌습니다. 나머지도 써달라고 할까요? 갑자기 현타가 오네요. 일하기 싫을 때 틈틈히 적어야겠습니다. 작성중 글이 10개를 넘어갑니다. 대박.
# 3. PSRC... WHAT?
# 4. 개발 삽질기
# 5. 마치며