EmDash CMS 플러그인 런타임 및 보안 모델
EmDash가 신뢰 플러그인과 샌드박스 플러그인 실행을 어떻게 분리하는지, 보안 경계에 Dynamic Workers가 왜 중요한지 이해합니다.
이 모델이 존재하는 이유
대부분의 CMS 플러그인 생태계는 같은 경계에서 실패합니다. 확장이 너무 많은 권한으로 실행됩니다.
EmDash는 플러그인 실행 모드를 분리하고 기능 경계를 명시적으로 만듦으로써 이를 다룹니다.
두 가지 실행 등급
신뢰 플러그인
- 애플리케이션 런타임의 일부로 로드됨
- 소유하거나 완전히 신뢰하는 코드에 적합
- 운영은 단순하지만 보안은 검토 규율에 달림
샌드박스 플러그인
- 격리된 worker 환경에서 실행됨
- 신뢰할 수 없거나 반신뢰 확장 로직용으로 설계됨
- 명시적 기능, 런타임 제한, 네트워크 규칙으로 제약됨
보안 자세는 플러그인 의도보다 런타임 격리 보장에 더 의존합니다.
아키텍처에서의 Dynamic Workers
Dynamic Workers는 Cloudflare에서 샌드박스 실행에 쓰이는 격리 원시 요소입니다.
없으면 샌드박스 모드를 사용할 수 없으며, 신뢰 플러그인 가정으로만 운영해야 합니다.
실무적으로:
- 무료 플랜: 코어 CMS는 동작, 샌드박스 플러그인 모드는 불가
- Dynamic Workers가 있는 유료 플랜: 샌드박스 모델 사용 가능
기능 모델: 기본적으로 최소 권한
플러그인은 필요한 것만 선언해야 합니다.
- 콘텐츠 읽기
- 특정 콘텐츠 도메인 쓰기
- 아웃바운드 네트워크 엔드포인트 호출
- 선택된 워크플로 훅 트리거
부여되지 않은 기능이면 작업은 결정적으로 실패해야 합니다. 이는 설계 요구사항이며 최선의 노력 수준의 예의가 아닙니다.
// 예: 기능 범위를 명시적으로 유지
export default definePlugin({
id: "notify-on-publish",
capabilities: ["read:content", "email:send"]
});중요한 런타임 가드레일
보안과 신뢰성 모두 하드 리미트에 달려 있습니다.
- CPU 및 벽시계(wall-time) 제한이 폭주 핸들러 방지
- 메모리 상한이 남용과 실수 누수 제약
- 네트워크 정책이 임의 유출 시도 차단
이 제어는 플러그인 실패를 플랫폼 장애가 아닌 경계 있는 사건으로 바꿉니다.
한 페이지로 보는 위협 모델
서드파티 플러그인은 다음을 포함할 수 있다고 가정하세요.
- 악의적 동작
- 오래된 의존성
- 드문 이벤트 타이밍의 로직 버그
따라서 플러그인 런타임은 다음을 보장해야 합니다.
- 피해 반경(containment)
- 권한 작업은 기본 거부
- 감사 가능한 실행 결과
신뢰는 설치로 주어지는 것이 아니라 정책으로 획득해야 합니다.
무료 플랜 운영 모델
샌드박스 지원 없이 운영할 때:
- 플러그인 세트를 최소로 유지
- 자사 또는 내부 검토 플러그인 선호
- 릴리스 게이트에서 의존성과 권한 검토
- 가능하면 위험한 통합은 외부 서비스로 분리
많은 팀에게 실행 가능한 모델이지만 더 강한 거버넌스 규율이 필요합니다.
결정 기준: 샌드박스 모드를 필수로 할 때
다음이면 샌드박스 모드를 필수로 다루세요.
- 외부 작성자 플러그인을 대규모로 설치할 때
- 규정 준수가 더 강한 격리 증거를 요구할 때
- 플러그인 침해에 따른 사업 위험이 실질적일 때
다음이면 선택 사항으로 다루세요.
- 플러그인 표면이 작고 완전히 감사됨
- 팀이 릴리스 파이프라인을 끝에서 끝까지 통제
실용 거버넌스 체크리스트
프로덕션에서 플러그인을 켜기 전에:
- 플러그인 소유자와 목적 문서화
- 필요한 기능과 아웃바운드 엔드포인트 검토
- 롤백 담당자와 롤백 절차 설정
- 실패 주입이 있는 스테이징에서 동작 검증
플러그인 보안은 일회성 아키텍처 결정이 아니라 런타임 경계에 뒷받침된 운영 프로세스입니다.