작은 구성에서 시작해 전사 구성까지

흐름

1. 개발자가 에이전트에 로그인합니다.
2. 에이전트가 DB 도구의 접속을 가로채 서버의 터널 포트로 보냅니다.
3. 게이트웨이가 판정한 뒤 DB 에 TLS 로 연결하고 로그인을 중계합니다.
4. 세션과 문장을 같은 서버의 PostgreSQL 에 기록합니다.

얻는 것

• 운영 DB 에 누가 언제 어떤 문장을 실행했는지 사람 이름으로 남습니다.
• 마스킹, SQL 통제, 접근 규칙을 바로 적용합니다.
• 개발자에게 베스천 서버의 SSH 계정을 나눠 주지 않아도 됩니다.

참고할 점

• DB 방화벽에서 다른 출발지를 닫아야 게이트웨이가 유일한 입구가 됩니다.
• 장애 때 사용할 비상 접속 경로를 미리 정합니다.

흐름

1. 관리자가 서비스를 선택해 접속 주소를 발급하고 발급 대상과 허용 대역을 정합니다.
2. 클라이언트는 호스트와 포트를 게이트웨이로 변경합니다. PostgreSQL, Oracle, SQL Server 는 DB 이름 앞에 발급받은 UUID 를 붙이고, MySQL 과 MariaDB 는 서비스마다 배정된 전용 포트로 접속합니다.
3. 게이트웨이가 출발지 IP 를 확인하고 실제 DB 로 로그인을 중계합니다.

얻는 것

• 사람을 더해도 방화벽을 다시 열 필요가 없습니다.
• 주소를 폐기하면 그 주소로는 곧바로 접속할 수 없습니다.

참고할 점

• 발급 대상은 감사에 남는 이름이고 본인 확인이 아닙니다. 실제로 접속을 제한하는 것은 허용 대역입니다.
• 사람을 정확히 구분해야 하는 접속에는 에이전트를 사용합니다.

흐름

1. 외주 개발자가 에이전트나 관리 콘솔에서 사유와 기간을 적어 접근을 신청합니다.
2. 미리 정한 결재 단계를 차례로 거칩니다.
3. 승인되면 신청한 기간만큼 허용하는 정책이 곧바로 게이트웨이에 배포됩니다.
4. 기간이 끝나면 새 접속을 거부하고 열려 있는 세션도 끊습니다.

얻는 것

• 필요한 사람에게 필요한 기간만 접속을 허용합니다.
• 조회 결과의 개인정보는 마스킹되고 모든 문장이 기록됩니다.

참고할 점

• 기간 만료는 게이트웨이가 스스로 확인합니다. Management 가 멈춰 있어도 세션이 끊깁니다.

흐름

1. 게이트웨이 노드가 등록 토큰으로 Management 에 스스로 등록하고 자기 클러스터의 정책만 받습니다.
2. 에이전트는 서비스마다 담당 클러스터의 주소를 받아 그곳으로 터널을 엽니다.
3. 모든 노드가 감사 저장소에 직접 기록합니다.

얻는 것

• DB 가 어느 망에 있든 정책과 감사를 한곳에서 관리합니다.
• 개발망의 게이트웨이는 운영 DB 의 정책과 접속 정보를 갖지 않습니다.
• 같은 등록 토큰으로 새 노드를 띄우면 곧바로 일을 시작합니다.

참고할 점

• 방화벽은 게이트웨이에서 Management 로 나가는 방향만 열면 됩니다.
• Management 는 한 대로 운영합니다.

흐름

1. 관리자가 서버의 SSH 를 서비스로 등록하고 호스트 키를 확정합니다.
2. 서버 계정마다 로그인 방식을 정하고, 접근 규칙에 명령 템플릿을 연결합니다.
3. 사용자는 에이전트에 로그인한 뒤 평소처럼 ssh 와 sftp 를 사용합니다.
4. 게이트웨이가 명령과 파일 전송을 판정하고 세션의 화면을 녹화합니다.

얻는 것

• 공용 계정 뒤의 사람을 구분해서 기록합니다.
• 대리 로그인을 사용하면 서버의 패스워드와 SSH 키를 사용자에게 나눠 주지 않아도 됩니다.
• 위험한 명령은 막고, 작업할 때만 필요한 명령은 승인받은 동안만 실행하게 합니다.

참고할 점

• 서버의 방화벽에서 게이트웨이 외의 SSH 출발지를 닫아야 게이트웨이가 유일한 입구가 됩니다.
• 에이전트 없는 접속과 웹 터미널은 아직 지원하지 않습니다.

흐름

1. 에이전트가 AI 서비스로 가는 접속을 가로채 게이트웨이로 보냅니다.
2. 게이트웨이가 TLS 를 풀어 요청을 읽고 사용자, 모델, 값 패턴을 검사합니다.
3. 패턴에 걸린 값만 마스킹해서 보내고 답변도 같은 패턴으로 마스킹합니다.

얻는 것

• AI 앱의 사용 내역을 사람 단위로 파악합니다.
• 개인정보와 자격 증명이 나가기 전에 마스킹하거나 막습니다.

참고할 점

• 요금은 로그인한 계정에 그대로 청구됩니다. 게이트웨이는 직원의 로그인 정보를 저장하지 않습니다.
• PC 에서 AI 서비스로 직접 나가는 길은 방화벽에서 닫습니다.

흐름

1. 관리자가 AI 서비스와 조직 키를 등록하고 가상 키를 발급합니다.
2. 애플리케이션이 가상 키를 넣어 게이트웨이로 요청합니다.
3. 게이트웨이가 규칙과 한도를 확인한 뒤 조직 키로 교체해 보내고 토큰 사용량을 집계합니다.

얻는 것

• 조직 키를 누구에게도 나눠 주지 않습니다.
• 비싼 모델을 막고 사용자마다 사용 한도를 정합니다.
• 연결 대상을 Amazon Bedrock 으로 옮겨도 애플리케이션의 설정은 그대로입니다.

참고할 점

• 클라이언트는 게이트웨이 클러스터의 루트 CA 를 신뢰해야 합니다.

흐름

1. 관리자가 MCP 서버의 도구 목록을 조회해 허용할 도구를 선택합니다.
2. 게이트웨이가 호출을 읽고 도구 이름과 인자를 검사합니다.
3. 허용이면 전달하고, 거부면 사유를 담은 오류를 돌려줍니다.

얻는 것

• 조회 도구는 허용하고 삭제 도구는 막습니다.
• 도구 호출 이력이 사람 이름과 함께 남습니다.

참고할 점

• 허용 목록이 비어 있으면 모든 도구를 허용합니다.
• PC 안에서만 실행되는 MCP 서버는 대상이 아닙니다.

흐름

1. 서버 한 대로 운영 DB 하나부터 시작합니다.
2. 에이전트를 사용할 수 없는 접속을 발급 주소로 더합니다.
3. DB 가 있는 망마다 게이트웨이 클러스터를 늘립니다.
4. 서버의 SSH 를 서비스로 등록합니다.
5. AI 서비스와 MCP 서버를 서비스로 등록합니다.

얻는 것

• 퇴사자의 계정을 끄면 열려 있는 DB 세션이 끊기고 AI 사용도 막힙니다.
• 값 패턴 하나를 DB 결과와 AI 프롬프트에 함께 사용합니다.
• 같은 사람의 SQL 문장, 서버 명령, AI 질문을 같은 이름으로 찾습니다.

참고할 점

• 감사 사본은 SIEM 으로 보냅니다.

흐름

1. 관리자가 프리셋 아홉 개에서 탐지 규칙을 복사해 켭니다.
2. Management 가 감사 저장소를 10초마다 읽어 규칙에 맞는 기록을 사람별 검토 건으로 묶습니다.
3. 검토자가 소명을 요청하면 당사자는 데스크톱 에이전트에서 답합니다.
4. 검토자가 위반, 정상 업무, 오탐 중에서 검토 결과를 남깁니다.
5. 매월 1일에 지난달의 월간 점검 보고서가 만들어집니다.

얻는 것

• 차단된 시도, 대량 조회, 업무시간 외 접근, 신규 IP 접속을 사람 단위로 봅니다.
• 정상 업무로 확인한 행위는 만료일까지 예외로 처리해 검토가 쌓이지 않습니다.
• 월간 점검 보고서가 점검하지 못한 구간까지 함께 알려 줍니다.

참고할 점

• 규칙은 켠 뒤에 발생한 기록에만 적용합니다.
• 소명은 데스크톱 에이전트로만 받습니다. 메일로는 받지 않습니다.