감사로그10 728x90 AI Agent를 위한 안전한 DB 접근 계층 API로 제한하는 실무 보안 설계 AI Agent의 DB 직접 접근을 막고 API로만 통제하는 설계AI 에이전트에게 DB 접속 권한을 직접 주면 편해 보이지만, 실제 운영에서는 다음 문제가 생깁니다.1) 과도한 행위 발생 위험AI는 의도와 다르게 쿼리를 넓게 만들 수 있습니다.너무 많은 row 조회불필요한 JOIN 확장민감 컬럼 포함 조회잘못된 UPDATE / DELETE 실행대량 export 성격의 쿼리 생성즉, 사람이 “이 정도만 조회하겠지”라고 생각해도, 모델은 맥락상 과하게 동작할 수 있습니다.2) 통제와 감사가 어려움SQL 직접 실행은 유연하지만, 그만큼 통제가 어렵습니다.어떤 사용 목적이었는지 추적이 어려움결과적으로 어떤 데이터를 노출했는지 추적이 어려움쿼리 한 번에 여러 테이블을 엮어 민감정보를 재구성할 수 있음악의적 프롬프.. 2026. 5. 28. AI 에이전트 샌드박스 아키텍처: just-bash 기반 실행 통제 게이트웨이 에이전트가 생성한 Bash 명령을 그대로 OS에 실행하지 않고, “게이트웨이”를 거쳐 다음을 보장합니다.안전성: 실제 디스크/네트워크/바이너리 실행 위험 최소화정책 준수: 명령 허용/차단/승인(HITL) + 접근제어 + 감사지원재현성: 동일 입력에 동일 결과(가상 FS, 실행 한도)운영성: 로깅/알림/리포트/사고조사(포렌식) 가능한 형태로 구조화just-bash를 게이트웨이 실행 엔진으로 쓰는 이유just-bash는 애초에 AI 에이전트용 “샌드박스 bash”로 설계되어,제공된 파일시스템만 접근 가능네트워크 기본 차단, 필요 시에도 URL prefix + HTTP method allowlist로 제한바이너리/WASM 실행 비지원(풀 VM 필요하면 Vercel Sandbox 권장)무한루프/재귀 방지(단, .. 2026. 2. 24. 내부망 LLM 기반 Internal AI Agent Platform (OpenClaw + MCP) 구축 목표 정의: “완전하게 활용”의 범위부터 딱 잡기내부 LLM + OpenClaw를 제대로 쓰려면, 목표를 아래 4개로 분해해 설계하는 게 안정적입니다.모델 계층: 내부망에서 LLM 추론(서빙) 제공에이전트 계층(OpenClaw): 대화/업무흐름/툴 호출/멀티에이전트 라우팅툴 계층(MCP 서버들): 사내 시스템(티켓/CMDB/로그/DB/웹자동화/파일) 기능을 표준 인터페이스로 제공운영·보안 계층: 권한/감사/네트워크/비밀정보/샌드박스/확장 코드 검증/관측성권장 아키텍처(레퍼런스)논리 구성LLM Inference(내부)선택지 A: Ollama(간편)선택지 B: vLLM/TGI(고성능/대규모)OpenClaw Gateway/Agent Workspaces워크스페이스(에이전트 단위) + 인증/라우팅/채널(메신저/웹.. 2026. 2. 14. OpenClaw(Moltbot,Clawdbot) AI 에이전트, 격리·최소권한·스킬 통제 OpenClaw를 한 문장으로 정의하면OpenClaw는 LLM(예: Claude/GPT)의 판단을 “메신저/대시보드 입력”과 “로컬/서버 도구 실행(파일·쉘·웹·채널)”로 연결하는 게이트웨이형 AI 에이전트 플랫폼입니다. 그래서 일반 챗봇과 달리, 설정 실수 = 곧바로 로컬/서버 침해면(attack surface)으로 이어질 수 있습니다.전체 구조(운영 관점) – “입력면 + 실행면” 분리해서 생각하기OpenClaw 운영을 안전하게 설계하려면, 아래 2면을 분리해 보셔야 합니다.입력면(대화 표면, Chat Surface)Control UI(브라우저 대시보드), WhatsApp/Telegram/Discord/Slack 등 채널누가/어디서/어떤 메시지를 보낼 수 있나 = 인증·승인·페어링의 영역실행면(도구/.. 2026. 2. 13. 키를 못 지키면 암호화도 무너진다 “KMS로 만드는 데이터 방어선“ 데이터 암호화는 단일 기술이 아니라 “계층형 방어 체계”입니다.아래 3개 축은 서로 대체 관계가 아니라 반드시 함께 작동해야 합니다.전송 암호화 (In Transit)저장 암호화 (At Rest)키 관리 (KMS · 엔벨로프 암호화 · 키 수명주기)핵심 원칙“데이터는 항상 암호화되어 있어야 하고,그 암호화 키는 데이터와 분리되어 중앙에서 통제되어야 한다.”전송 암호화 (Encryption In Transit)1. 개념과 배경전송 암호화는 네트워크를 이동 중인 데이터를 보호합니다.공격 시나리오내부망 스니핑중간자 공격(MITM)프록시/로드밸런서 구간 도청전송 암호화가 없으면→ 내부망 침해 시 모든 인증 정보·API Payload가 평문 노출2. 적용 대상클라이언트 ↔ 서버 (웹/모바일)서버 ↔ 서버 (마이크.. 2026. 2. 1. 이전 1 2 다음 728x90 728x90
