AACWorkflow Docs

런타임 샌드박스 정책

샌드박싱을 구현하여 런타임에서 실행 중인 에이전트의 파일 시스템 액세스, 명령 실행 및 네트워크 활동을 제한합니다.

샌드박스 정책을 사용하면 데몬에서 실행 중인 에이전트가 액세스하고 수행할 수 있는 작업을 제어할 수 있습니다. 파일 시스템 경로를 제한하고, 위험한 명령을 차단하고, 네트워크 연결을 제한하고, 필요에 따라 에이전트를 격리된 컨테이너에서 실행할 수 있습니다.

샌드박싱이 중요한 이유

에이전트는 강력합니다. 파일을 읽고, 명령을 실행하고, 네트워크 요청을 만들 수 있습니다. 샌드박싱 없이:

  • 데이터 유출 - 에이전트가 SSH 키, AWS 자격 증명 또는 기타 민감한 파일을 읽을 수 있습니다
  • 시스템 손상 - 에이전트가 중요한 파일을 삭제하거나 위험한 명령을 실행할 수 있습니다
  • 공급망 공격 - 손상된 기술이 데이터를 유출하거나 다른 시스템으로 피벗할 수 있습니다
  • 규정 위반 - 일부 규정 준수 프레임워크는 워크로드 격리를 요구합니다

샌드박스 정책은 경계를 강제함으로써 이러한 위험을 방지합니다.

샌드박스 정책 구성 요소

샌드박스 정책은 네 가지 측면을 제어합니다:

파일 시스템 액세스

허용 목록 - 에이전트가 읽고 쓸 수 있는 경로(및 하위 경로):

/home/user/workspace
/tmp
/var/tmp

거부 목록 - 항상 차단되는 경로(허용 목록에 있어도):

~/.ssh
~/.aws
~/.gnupg
/etc

기본적으로 AACWorkflow는 자격 증명 디렉터리 및 시스템 구성에 대한 액세스를 거부합니다. 더 많은 거부를 추가할 수 있지만 내장 거부 목록을 제거할 수 없습니다.

명령 실행

허용 목록 - 설정한 경우 이 명령만 실행할 수 있습니다. 공백 = 제한 없음.

git
grep
python

거부 목록 - 항상 차단되는 명령/패턴:

rm -rf /
chmod 777
curl | sh

거부된 명령은 즉시 실패하고 감사 항목을 남깁니다.

네트워크 액세스

허용 목록 - 에이전트가 연결할 수 있는 호스트명 및 CIDR 블록:

github.com
api.openai.com
10.0.0.0/8

거부 목록 - 항상 차단되는 호스트 및 패턴:

169.254.169.254  (AWS 메타데이터)
127.0.0.1:22  (로컬 SSH)

기본 동작은 런타임의 네트워크 정책에 따라 달라집니다.

실행기 유형

  • Local - 에이전트가 데몬 OS에서 직접 실행됩니다(기본값, 경량)
  • Container - 에이전트가 격리된 비권한 컨테이너에서 실행됩니다(더 안전함, Docker/Podman 필요)

샌드박스 정책 생성

샌드박스 정책은 에이전트별이 아닌 워크스페이스 수준에서 구성됩니다.

  1. 설정 → 보안 → 샌드박스 정책으로 이동합니다
  2. 기본 정책 검토합니다(이미 설정되어 있으며 자격 증명 디렉터리의 거부를 표시합니다)
  3. 파일 시스템 허용 목록 추가합니다 - 에이전트가 액세스해야 할 경로
  4. 파일 시스템 거부 추가합니다 - 명시적으로 차단할 경로(기본값 이외)
  5. 명령 제한 추가합니다(선택 사항) - 허용 목록 또는 거부 목록
  6. 네트워크 제한 추가합니다(선택 사항) - 허용 목록 또는 거부 목록
  7. 실행기 유형 선택합니다 - 로컬 또는 컨테이너
  8. 저장을 클릭합니다

거부가 허용을 재정의합니다: 경로가 허용과 거부 목록 모두에 있으면 거부가 이깁니다. 이는 광범위한 허용 목록이 있어도 자격 증명 디렉터리를 실수로 노출할 수 없도록 보장합니다.

파일 시스템 권한 세부 정보

허용 목록(에이전트가 액세스할 수 있는 항목)

에이전트는 허용 목록 항목과 일치하는 경로를 읽고 쓸 수 있습니다:

FilesystemAllow:
  - /home/user/workspace    # 에이전트가 이 디렉터리 및 하위 디렉터리에 액세스할 수 있습니다
  - /tmp                     # 에이전트가 /tmp를 사용할 수 있습니다
  - /var/data               # 에이전트가 /var/data에 액세스할 수 있습니다

작업별 작업 디렉터리는 정책에 관계없이 항상 허용됩니다.

거부 목록(에이전트가 액세스할 수 없는 항목)

거부 항목은 더 광범위한 허용 항목에 포함되어 있어도 항상 차단합니다:

FilesystemDeny:
  - ~/.ssh                  # SSH 키 거부
  - ~/.aws                  # AWS 자격 증명 거부
  - ~/.gnupg               # GPG 개인 키 거부
  - /etc                    # 시스템 구성 거부(내장 기본값)

내장 거부(제거할 수 없음):

  • ~/.ssh - SSH 키
  • ~/.aws - AWS 자격 증명
  • ~/.gnupg - GPG 개인 키
  • ~/.config/gh - GitHub CLI 구성
  • /etc - 시스템 구성
  • AACWorkflow 데몬 구성 디렉터리

이 목록에 더 추가할 수 있지만 내장 항목은 제거할 수 없습니다.

명령 제한 세부 정보

허용 목록(명령 화이트리스트)

허용 목록을 설정한 경우 목록의 명령만 실행할 수 있습니다:

CommandAllow:
  - git          # 에이전트가 'git' 실행 가능
  - grep         # 에이전트가 'grep' 실행 가능
  - python       # 에이전트가 'python' 실행 가능
  - python3      # 에이전트가 'python3' 실행 가능

다른 명령은 오류로 실패합니다.

허용 목록이 비어 있으면 모든 명령이 허용됩니다(거부 목록으로 차단되지 않은 경우).

거부 목록(명령 블랙리스트)

거부 목록의 명령은 실행되지 않습니다:

CommandDeny:
  - rm -rf /         # 파괴적인 삭제 차단
  - chmod 777        # 권한 변경 차단
  - curl | sh        # 다운로드 및 실행 차단
  - sudo             # 권한 상승 차단
  - :(){ :|:& };:    # 포크 폭탄 차단

거부된 명령을 시도할 때:

  • 실행이 명확한 오류로 실패합니다
  • 감사 항목이 기록됩니다
  • 에이전트가 통보받고 다른 방법을 시도할 수 있습니다

내장 거부 패턴

AACWorkflow는 알려진 위험 명령에 대한 내장 거부 패턴을 포함합니다:

  • 파일 삭제: rm -rf, dd if=/dev/zero
  • 권한 변경: chmod 777, chown, sudo
  • Git 역사 변조: main/master로 git push --force
  • 셸 폭탄: :(){ :|:& };:
  • 원격 코드 실행: curl | sh, wget -qO- | sh
  • Reverse shells: Netcat, reverse-shell 서명

내장을 제거하지 않고 더 많은 패턴을 추가할 수 있습니다.

네트워크 제한 세부 정보

허용 목록(승인된 대상)

에이전트는 허용 목록의 호스트명 및 네트워크에 연결할 수 있습니다:

NetworkAllow:
  - github.com              # 에이전트가 GitHub에 연결할 수 있습니다
  - api.openai.com          # 에이전트가 OpenAI를 호출할 수 있습니다
  - 10.0.0.0/8              # 에이전트가 10.x.x.x에 도달할 수 있습니다
  - "*.internal.example.com" # 에이전트가 *.internal에 도달할 수 있습니다

거부 목록(차단된 대상)

에이전트는 이 호스트명/네트워크에 연결할 수 없습니다:

NetworkDeny:
  - 169.254.169.254  # AWS EC2 메타데이터 서비스
  - 127.0.0.1:22     # 로컬 SSH
  - 0.0.0.0/0        # 모두 차단(허용 목록과 결합된 경우)

거부된 연결은 소켓 수준에서 차단되고 감사됩니다.

컨테이너 실행기(고급)

최대 격리를 위해 비권한 컨테이너 내에서 에이전트를 실행할 수 있습니다:

  1. 설정 → 보안 → 샌드박스 정책으로 이동합니다
  2. 실행기 아래에서 컨테이너를 선택합니다
  3. 선택적으로 컨테이너 특정 설정을 구성합니다:
    • 메모리 제한(예: 2GB)
    • CPU 제한(예: 2개 코어)
    • 네트워크 모드(기본적으로 격리됨)
  4. 저장을 클릭합니다

전제 조건:

  • Docker 또는 Podman이 데몬에 설치되어야 합니다
  • 데몬 프로세스가 컨테이너를 생성할 권한을 가져야 합니다
  • 비권한 모드가 권장됩니다(root로 실행하는 것보다 안전함)

발생하는 일:

  • 에이전트 작업이 컨테이너 내에서 실행됩니다
  • 작업별 작업 디렉터리가 바인드 마운트됩니다
  • 샌드박스 정책의 파일 권한이 적용됩니다
  • 네트워크는 NetworkAllow에 따라 격리됩니다
  • 작업이 완료되면 각 컨테이너가 삭제됩니다

절충:

  • 장점: 진정한 격리, 삭제된 Linux 기능, 읽기 전용 루트 파일 시스템
  • 단점: 약간의 성능 오버헤드, 컨테이너 런타임 필요, 더 복잡한 디버깅

유효한 정책 보기

설정 페이지에서 다음을 볼 수 있습니다:

  • 내장 기본값 - AACWorkflow가 기본적으로 적용하는 항목
  • 사용자 정의 항목 - 추가하거나 사용자 지정한 항목
  • 유효한 정책 - 병합된 결과

예:

Built-in deny:  ~/.ssh, ~/.aws, /etc
Your additions: /root/.kube, ~/confidential
Effective deny: ~/.ssh, ~/.aws, /etc, /root/.kube, ~/confidential

샌드박스 위반 감사

모든 샌드박스 정책 위반이 기록됩니다:

  • 경로 액세스 거부
  • 명령 실행 실패
  • 네트워크 연결 차단

설정 → 감사 로그에서 감사 로그를 보고 "샌드박스" 또는 "보안"으로 필터링하여 다음을 확인하세요:

  • 어떤 에이전트가 언제 거부된 경로에 액세스하려고 했는지
  • 어떤 명령이 차단되었고 왜
  • 어떤 네트워크 연결이 거부되었는지

이 로그를 사용하여:

  • 에이전트가 합법적으로 액세스가 필요한 경우 정책 조정
  • 의심스러운 동작 조사
  • 감사 요구 사항 준수

최상의 실천 방법

  • 제한적으로 시작 - 기본적으로 거부, 필요한 것 허용
  • 컨테이너 실행기 사용 - 신뢰할 수 없거나 고위험 작업의 경우
  • 정기적으로 거부 검토 - 에이전트가 거부 규칙을 누르면 조사
  • 위협 감지와 쌍 - 샌드박스 정책 + 위협 감지 함께
  • 허용 목록 문서화 - 특정 경로/명령이 필요한 이유를 팀과 공유
  • 프로덕션 전 테스트 - 먼저 테스트 런타임에서 정책 활성화

제한 사항

  • 로컬 모드는 최선의 노력 - 호스트 OS의 샌드박싱은 OS 수준 보호에 의존하며 때로는 우회될 수 있습니다
  • 내장 거부를 제거할 수 없음 - 자격 증명 디렉터리는 항상 보호됩니다
  • 컨테이너 모드에는 런타임 필요 - Docker 또는 Podman 설치 필요
  • 네트워크 허용 목록이 정확함 - 와일드카드 패턴은 지원이 제한적입니다. 광범위한 대상에는 IP 범위 사용

다음 단계

이 페이지에서

샌드박싱이 중요한 이유샌드박스 정책 구성 요소파일 시스템 액세스명령 실행네트워크 액세스실행기 유형샌드박스 정책 생성파일 시스템 권한 세부 정보허용 목록(에이전트가 액세스할 수 있는 항목)거부 목록(에이전트가 액세스할 수 없는 항목)명령 제한 세부 정보허용 목록(명령 화이트리스트)거부 목록(명령 블랙리스트)내장 거부 패턴네트워크 제한 세부 정보허용 목록(승인된 대상)거부 목록(차단된 대상)컨테이너 실행기(고급)유효한 정책 보기샌드박스 위반 감사최상의 실천 방법제한 사항다음 단계