언제나 나만의 고유한 아이덴티티
각 협업자는 당사의 ID 레이어인 Keycloak을 통해 각자의 계정으로 로그인합니다. 아무도 귀하의 비밀번호를 입력하지 않고, 아무도 브라우저 세션을 공유하지 않으며, 누군가를 제거하는 작업은 비밀번호를 교체하고 누가 알고 있었는지 파악하기 위해 우왕좌왕할 필요 없이 한 번의 조치로 완료됩니다.
위임된 액세스
사람들에게 필요한 정확한 권한만 부여하세요 — 그 이상은 필요하지 않습니다
개발자를 참여시키거나, 회계사에게 청구 업무를 맡기거나, 고객에게 자체 사이트에 대한 읽기 전용 접근 권한을 부여하거나, 지원 팀이 문제를 검토하도록 할 수 있습니다. 모든 권한 부여는 정의된 권한을 가진 역할로서 조직으로 범위가 제한되고, 데이터베이스에서 적용되며, 추가 전용 감사 로그에 기록됩니다.
- 94세부 권한
- 12기본 제공 역할
- 8직원 부서
- 700,000+전 세계에서 호스팅되는 사이트
액세스는 공유된 비밀번호가 아니라 멤버십입니다
하나의 로그인 정보를 공유하면 계정 액세스에 문제가 발생합니다. Zinn Digital®에서는 모든 사용자가 고유한 신원을 가지며, 액세스는 멤버십(사용자, 조직, 역할)으로서 개별적으로 부여, 변경 또는 취소할 수 있습니다.
조직이 트리 구조를 형성합니다
계정은 계층 구조로 이루어져 있습니다. 리셀러 조직은 고객 조직을 포함하고, 고객 조직은 사이트를 포함합니다. 멤버십은 조직과 그 하위의 모든 항목에 적용되므로, 다른 고객을 노출하지 않고도 에이전시 고객에게 해당 조직에 대한 제어 권한을 부여할 수 있습니다.
데이터베이스에서 격리가 적용됨
테넌트 분리는 버그로 인해 건너뛸 수 있는 애플리케이션 코드의 필터가 아닙니다. Postgres 행 수준 보안(Row-Level Security)은 모든 쿼리의 범위를 호출자의 조직 하위 트리로 한정하므로, 귀하의 범위를 벗어난 요청에는 반환할 데이터가 없습니다.
부재는 보이지 않습니다
범위 밖의 조직이나 사이트를 요청하면 API는 권한 오류 대신 단순한 '찾을 수 없음'으로 응답합니다. 권한 오류는 레코드가 존재함을 확인해 주지만, '찾을 수 없음'은 외부인에게 아무것도 알려주지 않습니다.
4개의 고객 역할, 35개의 권한
권한은 sites.restart 또는 billing.refund와 같이 모듈과 작업으로 구성된 세분화된 키이며, 역할은 이를 묶어줍니다. 4가지 역할이 실제 팀에 필요한 형태를 지원하며, 각 역할은 코드에 묻혀 있는 로직이 아니라 당사가 초기 입력하는 데이터입니다.
소유자
완전한 제어: 하위 조직 생성, 구성원 초대 및 제거, 역할 변경, API 키 관리, 사이트 생성, 재시작, 제거, 정지 및 삭제, 청구 및 인보이스 발행, 티켓 생성, 감사 로그 확인. 자신을 위해 유지하는 역할입니다.
청구 관리자
조직, 구성원 및 요금제 카탈로그를 확인하고, 인보이스, 결제 수단 및 청구 금액을 관리합니다. 단 하나의 사이트도 생성, 수정 또는 삭제할 수 있는 권한이 없습니다. 외부 회계 담당자에게 정확히 필요한 권한 구성입니다.
개발자
사이트를 조회 및 생성하고, 서비스를 다시 시작하고, 캐시를 삭제하고, API 키를 관리하며, 티켓을 처리합니다. 의도적으로 제외된 항목: 결제, 인보이스, 결제 수단, 회원 관리, 사이트 일시 중단 및 사이트 삭제. 계약업체는 귀하에게 비용을 청구하거나 어떤 것도 파괴하지 않고 작업을 구축할 수 있습니다.
읽기 전용
조직, 구성원, 사이트, 결제 정보, 플랜 카탈로그, 티켓, 번역 상태 및 감사 로그를 볼 수 있으며, 이 중 어떤 것도 변경할 수 없습니다. 가시성을 원하는 고객, 감사자 또는 조회만 필요한 이해관계자에게 적합한 권한입니다.
팀이 임의로 약화시킬 수 없는 로그인
액세스 위임은 위임받는 계정을 탈취하기 어려운 경우에만 안전합니다. 계정의 모든 사용자에 대해 모든 환경에서 Keycloak을 통해 인증이 실행됩니다.
- 피싱 방지 로그인을 위한 패스키와 WebAuthn은 물론, 정책에 따라 모든 사용자에게 필수로 적용되는 TOTP 2단계 인증을 제공합니다. 이는 팀원이 건너뛸 수 있는 선택적 설정이 아닙니다.
- 기본 옵션인 매직 링크 이메일 로그인, 대체 수단으로서의 이메일 및 비밀번호, 그리고 Google, Microsoft, GitHub 등을 통한 소셜 로그인.
- 기업 및 에이전시 고객을 위한 SAML 싱글 사인온으로, 입사자와 퇴사자를 수동이 아닌 ID 공급자가 직접 처리합니다.
- 고객 대시보드, 공개 사이트, 지식 베이스 및 지원 티켓 전반에 걸친 단일 세션 — 한 번 로그인하고, 한 번에 취소하세요.
- 세션 정책, 민감한 작업에 대한 단계별 인증, 알려진 네트워크로만 액세스를 제한하려는 계정을 위한 조직별 선택적 IP 허용 목록.
- 계정이 생성되기 전에 모든 가입 이메일의 유효성을 검사하므로, 배달 불가능한 주소, 일회용 주소, 역할 기반 주소는 나중에 고아 멤버로 남는 대신 입구에서 바로 차단됩니다.
저희 팀에 액세스가 필요한 경우, 범위가 제한되며 기록이 남습니다
지원 업무를 진행하다 보면 귀하의 계정 내부를 확인해야 하는 경우가 있습니다. 해당 접근 권한은 다른 모든 것과 동일한 권한 모델에 의해 관리됩니다. 직원은 좁은 범위의 권한을 부여받은 부서로 구성된 직원 조직에 단순히 소속되어 있습니다.
전체 관리자가 아닌 부서
직원은 지원, 청구 및 재무, 어뷰징 및 신뢰·안전, 영업, 온보딩, 엔지니어링 및 운영, 마케팅, 경영진으로 분류됩니다. 각 역할마다 특정 모듈과 작업 권한이 부여되므로, 담당자는 업무에 필요한 관리 콘솔 부분만 볼 수 있고 나머지 부분은 볼 수 없습니다.
지원 담당자의 진정한 한계
Support Agent 역할은 정확히 다음 권한만을 부여합니다: 고객 조회, 티켓 조회 및 응답, 사이트 조회, 사이트 재시작 및 캐시 삭제. 이 역할에는 결제 구성, 환불 처리, 요금제 수정 및 플릿 관리 권한이 포함되지 않습니다. 상담원이 수행할 수 있는 문제 해결 작업은 선의가 아니라 부여된 역할에 의해 제한됩니다.
고객으로 로그인하는 것은 엄격하게 제한됩니다
customer.impersonate 권한은 Manager 역할의 일부가 아니며 Super Admin만 보유합니다. 귀하를 대신하여 세션이 실행 중인 경우, 대시보드에 지속적인 가장(impersonation) 배너가 표시되어 누가 작업 중인지 항상 명확하게 알 수 있습니다.
특권이 부여된 모든 사항은 서면으로 기록됩니다
모든 권한 있는 작업 및 관리 작업은 행위자, 작업, 대상, 지원 메타데이터, IP 주소 및 타임스탬프를 기록하는 추가 전용 감사 로그에 추가되며, 프로덕션 환경에서는 시간별로 파티션 분할됩니다. 소유자와 읽기 전용 구성원은 자신이 속한 조직의 로그를 직접 읽을 수 있습니다.
파괴적 작업에 대한 승인 게이트
민감하고 파괴적인 영향을 미칠 수 있는 직원의 작업은 실행 전에 단계별 인증이나 두 사람의 승인을 요구할 수 있으며, 새로운 부서와 역할은 코드 변경 없이 구성 설정만으로 처리됩니다.
머신에도 위임된 액세스 권한이 부여됩니다
스크립트, CI 파이프라인, CLI, Terraform 공급자 및 AI 에이전트는 모두 사람과 동일한 권한 모델을 통해 인증됩니다. 공유된 사람의 자격 증명도 없고, 빌드에 붙여넣은 수명이 긴 시크릿도 없습니다.
API 키는 조직별로 적용되며 범위가 지정됩니다
키는 조직에 속하며 동일한 RBAC 권한(읽기 전용, 결제, 프로비저닝)에 연결된 세부적인 범위를 가집니다. 파이프라인에 멤버의 전체 계정 대신 필요한 최소한의 범위만 부여하십시오.
샌드박스 키는 프로덕션과 별개입니다
테스트 모드와 라이브 모드 키는 서로 구별되므로, 개발 중인 연동 작업이 실수로 또는 복사된 환경 변수로 인해 프로덕션 데이터에 접근할 수 없습니다.
해시만 저장됩니다
비밀 값의 SHA-256 해시와 조회 접두사만 저장하며, 원본 키는 절대 저장하지 않습니다. 키는 생성 시점에 단 한 번만 확인할 수 있습니다. 각 키는 마지막으로 사용된 시점을 추적하며, 다른 항목에 영향을 주지 않고 개별적으로 취소할 수 있습니다.
AI 도구는 귀하의 권한에 따라 연결됩니다
당사의 MCP 서버를 사용하면 MCP 지원 에이전트가 자연어로 귀하의 호스팅을 관리할 수 있으며, OAuth 2.1로 인증되고 조직 및 RBAC 역할로 범위가 지정되며 도구별 철회 가능한 토큰, 파괴적인 작업에 대한 확인, 지출 한도 및 전체 감사 로깅이 제공됩니다.
사이트 자체에 대한 액세스
계정 액세스와 서버 액세스는 서로 다른 문제입니다. 사이트 수준의 자격 증명은 대시보드에서 관리되고, 최소 권한으로 발급되며, 한 협업자의 셸이 한 사이트의 셸로만 제한되도록 격리됩니다.
- 격리된 셸(jailed shell)이 포함된 SSH, 그리고 SFTP 및 FTP — CageFS 격리를 통해 각 테넌트는 자신의 파일만 볼 수 있습니다.
- 개발자가 실제로 스크립트화하려는 작업을 위한 패널 터미널 및 SSH를 통한 wp-cli.
- code-server를 통해 브라우저에서 사용할 수 있는 완전한 VS Code 에디터로, git을 지원하며 대시보드에서 사이트 파일을 직접 편집할 수 있습니다.
- 데이터베이스를 위한 임베디드 phpMyAdmin 및 Adminer, 그리고 임베디드 파일 관리자. 두 기능 모두 두 번째 자격 증명을 요구하는 대신 대시보드에서 싱글 사인온(SSO)으로 직접 연결됩니다.
- 액세스 키와 자격 증명은 대시보드에서 생성, 나열, 교체 및 취소되며, 최소 권한 원칙으로 발급되고, 사용 내역은 감사 로그에 기록됩니다.
- 복제 및 라이브 배포 기능을 갖춘 스테이징 환경은 위험한 작업을 운영 환경으로부터 격리하므로, 새로운 공동 작업자의 첫 변경 사항이 라이브 사이트에 바로 적용되지 않습니다.
실제 업무 방식에 맞게 액세스를 구성하는 방법
1인 운영자는 단일 조직과 하나의 소유자 멤버십을 유지하며, 프로젝트를 위해 계약업체가 참여할 때 개발자 역할을 추가합니다. 프로젝트가 종료되면 멤버십이 삭제되고 해당 사용자의 로그인이 즉시 중단되므로, 교체해야 할 공유 자격 증명이 남지 않습니다.
에이전시는 조직 트리를 사용합니다. 각 고객은 해당 고객의 사이트를 포함하는 자체 하위 조직을 가지게 되며, 고객의 담당자는 해당 하위 조직의 멤버십을 받습니다. 가시성을 원하는 이해관계자에게는 읽기 전용 권한이, 셀프 서비스를 원하는 고객에게는 소유자 권한이 부여됩니다. 귀하의 직원은 트리 상위 수준의 멤버십을 보유하여 포트폴리오를 확인할 수 있으며, 고객은 자신의 브랜치만 보게 됩니다. 이를 단순한 약속이 아닌 실제로 구현하는 것이 바로 Row-Level Security입니다.
리셀러는 한 단계 더 높은 위치에서 동일한 방식으로 작동합니다. 리셀러 조직은 클라이언트 조직들을 보유하며, 각 클라이언트 조직은 자체 멤버, 청구 내역 보기 및 사이트를 가집니다. 동일한 기본 요소가 하위 계정, 에이전시 팀 및 리셀러 계층 구조를 지원하며, 그 어떤 것에도 별도의 덜 강력한 메커니즘이 사용되지 않습니다.
카드 등록이 필요 없는 14일 무료 체험을 통해 모든 기능을 이용하실 수 있습니다. 결제 정보 없이 가입하고, 동료를 초대하여 각 역할별로 접근 가능한 항목과 불가능한 항목을 확인하고, 직접 감사 로그를 검토해 보세요.
자주 묻는 질문
한 사이트에 대해서만 다른 사용자에게 접근 권한을 부여할 수 있나요?
현재 멤버십은 조직 전체와 계층 구조상 그 하위에 있는 모든 항목에 걸쳐 역할을 부여하므로, 사이트 세트를 분리하는 방법은 조직을 분리하는 것입니다. 해당 사이트들을 자체 하위 조직에 배치하고 그곳에서 멤버십을 부여하십시오. 이는 각 클라이언트가 이미 자체적인 경계를 원하는 대행사 및 리셀러에게 깔끔한 모델입니다. 단일 조직 내에서 지정된 사이트에 단일 멤버십을 고정하는 멤버십별 리소스 범위 지정은 현재 제공되는 기능이 아니라 계획된 개선 사항입니다.
초대한 개발자가 사이트를 삭제하거나 라이브 환경에 배포할 수 있나요?
Developer 역할에는 사이트 삭제 또는 사이트 일시 중단 권한이 포함되지 않으며, 해당 권한은 Owner 역할에 속합니다. 이 역할은 사이트 조회 및 생성, 서비스 재시작, 캐시 삭제, API 키 관리, 티켓 처리 권한을 부여합니다. 배포 및 push-to-live 권한 또한 Developer에게 부여되지 않으므로, 프로덕션 환경으로의 반영 권한은 계정 소유자에게 유지됩니다. 빌드 작업이 처음부터 라이브 사이트 외부에서 이루어질 수 있도록 이를 스테이징과 함께 활용하십시오.
Zinn Digital® 직원은 내 계정에서 무엇을 볼 수 있나요?
이는 전적으로 직원의 역할에 따라 달라지며, 각 역할은 세분화된 권한 키의 집합입니다. 예를 들어 Support Agent는 귀하의 계정과 사이트를 확인하고, 티켓을 조회 및 답변하며, 사이트를 재시작하고 캐시를 삭제할 수 있지만 청구 설정, 환불, 플랜 또는 플릿을 수정할 수는 없습니다. 고객으로 로그인하는 것은 Super Admin에게만 부여된 별도의 권한이며, 이 경우 대시보드에 지속적인 가장(impersonation) 배너가 표시됩니다. 모든 권한 관련 작업은 작업자, 작업, 대상, IP 및 타임스탬프와 함께 감사 로그에 기록되며, 귀하의 조직 로그는 직접 확인하실 수 있습니다.
누군가 퇴사할 경우 신속하게 접근 권한을 취소하려면 어떻게 해야 하나요?
멤버십을 삭제하면 해당 조직에 대한 액세스 권한이 종료됩니다. 해당 사용자의 고유한 ID는 유지되지만 역할이 사라지므로 계정 내 권한도 모두 제거됩니다. API 키는 개별적으로 취소되므로 다른 작업에 영향을 주지 않고 파이프라인 키만 해제할 수 있습니다. SAML 싱글 사인온을 사용하는 경우, ID 공급자에서 프로비저닝을 해제하면 로그인이 중앙에서 관리됩니다. SSH 키와 같은 사이트 수준의 자격 증명은 대시보드에서 취소되며, 삭제 작업 자체는 감사 로그에 기록됩니다.
팀 구성원이 내 API 키를 공유하나요?
아닙니다 — 하지만 그 이유를 명확히 짚고 넘어갈 가치가 있습니다. API 키는 개별 멤버가 아닌 조직에 속하며, 동일한 권한 카탈로그에 연결된 자체 세부 스코프를 갖습니다. 따라서 특정 개인에게 키를 전달하기보다는, 해당 작업에 필요한 가장 좁은 범위의 스코프를 적용하여 수행할 작업 전용 키를 생성하고 작업이 끝나면 해당 키를 취소합니다. 시크릿의 해시만 저장되며, 각 키에는 마지막으로 사용된 시점이 기록되므로 사용하지 않는 키를 쉽게 찾아 폐기할 수 있습니다.
모든 것에 대한 키를 제공하지 않고도 AI 에이전트를 연결할 수 있습니까?
예. 저희 MCP 서버는 OAuth 2.1을 통해 에이전트를 인증하고, 도구별로 취소 가능한 토큰을 사용하여 귀하의 조직 및 RBAC 역할로 범위를 제한하므로 포괄적인 접근 권한 대신 특정 기능을 부여할 수 있습니다. 파괴적인 작업에는 확인이 필요하고 지출 한도가 적용되며, 모든 작업은 인간 활동과 동일한 감사 로그에 기록됩니다.
한 테넌트가 다른 테넌트의 데이터에 접근하는 것을 막는 것은 무엇입니까?
Postgres Row-Level Security는 쿼리 범위를 데이터베이스 자체 내에서 호출자의 조직 하위 트리로 한정하며, 애플리케이션 수준의 필터는 유일한 방어선이 아닌 심층 방어로 작동합니다. 범위를 벗어난 레코드에 대한 요청은 권한 오류 대신 '찾을 수 없음'을 반환하므로 존재하는 항목에 대한 정보가 전혀 노출되지 않습니다. 서버 측에서는 CageFS를 통한 사이트별 격리를 통해 각 테넌트의 셸과 파일을 자체 사이트로만 제한합니다.
결제하기 전에 이것을 먼저 사용해 볼 수 있나요?
예. 14일 무료 체험은 카드 등록이 필요 없으며 — 결제 정보도, 약정도 없습니다 — 최대 5개 사이트를 위한 Footprint-Free 호스팅을 지원합니다. 최종 결정을 내리기 전에 동료를 초대하고, 역할을 할당하며, 경계가 요구 사항대로 작동하는지 확인하기에 충분합니다.
관련 항목
명확히 짚을 수 있는 경계를 정해 위임하십시오
카드 등록이 필요 없는 14일 무료 체험을 시작하고, 팀원을 초대하여 권한 모델의 작동 방식을 직접 확인해 보세요. 직접 이름을 지정할 수 있는 역할, 취소 가능한 범위, 그리고 누가 무엇을 했는지 정확히 기록하는 감사 로그가 제공됩니다.
무료로 시작하기