업데이트됨

Slack에서 비밀번호를 절대 공유하지 마세요: 위험성과 더 안전한 대안

작성자

Slack에서 비밀번호를 공유하는 것은 보안 위험입니다. Slack은 메시지를 무기한 보존하고, 워크스페이스 관리자가 검색할 수 있게 만들며, 서드파티 앱 통합에 노출시키기 때문이에요. 대신 암호화된 자기파괴 링크를 사용하세요 — Vaulted 같은 도구는 무언가를 전송하기 전에 브라우저에서 자격 증명을 암호화합니다.

Verizon 2025 DBIR에 따르면, 데이터 침해 사고의 22%에서 손상된 자격 증명이 최초 공격 경로였습니다. 그리고 Beyond Identity 연구에 따르면, 직원의 41% 이상이 업무용 비밀번호를 공유한 경험이 있으며, 종종 채팅이나 이메일 같은 안전하지 않은 채널을 통해서입니다.

그 비밀번호에 실제로 무슨 일이 일어나는가

Slack에 자격 증명을 붙여넣으면, 단순히 상대방에게 전달되는 것으로 끝나지 않아요. 그것은 Slack이 저장하고, 색인화하고, 보존하는 데이터가 됩니다 — 당신이 잊어버린 지 한참이 지난 후에도요.

Slack은 자체 서버에 메시지를 보존합니다. 유료 요금제에서는 워크스페이스 관리자가 보존 정책을 구성할 수 있지만, 많은 곳에서 기본 설정을 그대로 둡니다: 모든 것을 영원히 유지. Enterprise Grid에서는 조직이 모든 DM과 채널의 전체 기록을 내보내고 검색할 수 있습니다 — 개인 사용자 간의 메시지도 포함해서요.

Slack 메시지는 검색 가능합니다. 적절한 권한을 가진 사람이라면 워크스페이스 전체에서 키워드를 검색할 수 있어요. 대부분의 워크스페이스에서 "password"나 "API key"로 검색하면 보안 감사자가 움찔할 결과들이 나옵니다.

서드파티 앱이 메시지를 읽을 수 있습니다. 적절한 OAuth 스코프를 가진 모든 Slack 앱은 메시지 기록에 접근할 수 있어요. 팀이 작년에 설치한 생산성 봇? 채널과 DM에 대한 읽기 권한이 있을 수 있습니다. 당신은 Slack의 보안만이 아니라 워크스페이스에 연결된 모든 통합의 보안도 신뢰하는 거예요.

메시지는 퇴사 후에도 남습니다. 누군가 회사를 떠나도 그들의 Slack 메시지는 남아 있어요. 데이터베이스 비밀번호가 담긴 그 DM? 계정이 비활성화된 후에도 관리자가 읽을 수 있는 상태로 여전히 거기 있습니다.

GitGuardian의 2025 State of Secrets Sprawl 보고서에 따르면, 기업 Slack 채널의 2.4%에 유출된 시크릿이 포함되어 있었습니다. 그리고 IBM Cost of a Data Breach Report 2025는 전 세계적으로 데이터 침해의 평균 비용이 444만 달러에 달했다고 밝혔습니다.

컴플라이언스 문제

회사가 SOC 2, ISO 27001, 또는 HIPAA 컴플라이언스를 준비하고 있다면, Slack에서 자격 증명을 공유하는 것은 언젠가 발견될 지적 사항입니다.

감사자들은 팀이 내부적으로 민감한 자격 증명을 어떻게 전송하는지 구체적으로 묻습니다. "Slack에 붙여넣는다"는 그들이 원하는 답이 아니에요 — 그리고 인증을 지연시키거나 막을 수 있습니다.

SOC 2 Trust Services Criteria는 민감한 데이터 전송 방식에 대한 통제를 요구합니다. 뷰 제한과 암호화가 있는 자기파괴 링크는 그 통제를 충족합니다. Slack 메시지는 그렇지 않아요.

대신 해야 할 일

해결책은 간단합니다: 기기를 떠나기 전에 자격 증명을 암호화하고, 조회 후 자기파괴되는 링크를 공유하세요.

브라우저에서

  1. vaulted.fyi에 접속
  2. 비밀번호나 자격 증명 붙여넣기
  3. 조회 1회 후 만료되도록 설정
  4. Slack (또는 어디서든) 링크 전송

자격 증명은 클라이언트 측 암호화를 사용해 브라우저에서 AES-256-GCM으로 암호화됩니다. 복호화 키는 URL 프래그먼트에만 존재합니다 — 서버에는 절대 전달되지 않아요. 동료가 링크를 열면, 시크릿은 영구적으로 삭제됩니다.

이제 누군가 Slack에서 "password"를 검색하면, 활성 자격 증명 대신 만료된 링크만 찾게 됩니다.

터미널에서

커맨드라인이 주 무대라면, Vaulted CLI가 동일한 작업을 수행합니다:

npx vaulted-cli "staging-db-password" --views 1 --expires 1h

파이프로 연결하고, 스크립트로 만들고, 별칭으로 등록하세요. 동일한 종단 간 암호화, 동일한 자기파괴 링크입니다.

CI/CD 워크플로에서

GitHub Actions 워크플로 간에 자격 증명을 공유하고 있나요? Vaulted GitHub Action도 그걸 처리해줍니다:

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.DEPLOY_KEY }}
    views: 1
    expires: 1h

팀을 위한 간단한 규칙

  1. 어떤 채팅 앱에도 자격 증명을 직접 붙여넣지 마세요 — Slack, Teams, Discord, 어디도 안 됩니다
  2. 자기파괴 링크를 사용하세요 — 조회 1회, 짧은 만료 시간, 항상
  3. 민감한 자격 증명에는 패스프레이즈를 추가하세요 — 별도 채널로 전달하세요 (전화, 직접)
  4. 공유 후 자격 증명을 교체하세요 — 모든 전달을 잠재적 노출로 취급하세요
  5. 팀 정책을 수립하세요 — 암호화 공유를 예외가 아닌 기본으로 만드세요

Slack에 있는 그 비밀번호는 순간적으로 무해해 보입니다. 하지만 그것은 검색 가능하고, 영구적이며, 잘못 구성된 통합 하나로 노출될 수 있어요.

대신 안전하게 공유하세요 — 똑같이 3초면 됩니다.


관련 링크