SaaS 보안 완전 정복 — 2026년 기업이 반드시 알아야 할 7가지 핵심 전략
이 글을 끝까지 읽으면, 우리 회사 SaaS 계정 하나하나가 어떻게 보안 사고의 시작점이 되는지, 그리고 2026년 바뀐 규제 환경에서 무엇부터 손봐야 하는지 명확하게 알게 됩니다. SSPM부터 망분리 예외, 공급망 공격까지 현장 실무 기준으로 정리했습니다.
안녕하세요. ICT리더 리치입니다. 솔직히 말하면, 몇 년 전까지만 해도 "SaaS 보안"이라고 하면 그냥 비밀번호 잘 관리하고 2단계 인증 켜두면 끝이라고 생각했습니다.
그런데 실제로 컨설팅 현장에서 기업들의 SaaS 계정 목록을 받아보면 상황이 완전히 다릅니다. 팀마다 제각각 가입한 SaaS가 수십 개씩 쌓여 있고, 퇴사한 직원 계정이 그대로 살아있고, 외부 협력사에 과도한 권한이 부여된 채 방치된 경우를 너무 많이 봤습니다.
2026년 4월부터는 금융권 내부 업무망에서도 SaaS 활용에 대한 망분리 규제 예외가 시행되면서, 이제 SaaS는 선택이 아니라 인프라의 한 축이 되었습니다.
오늘은 SaaS가 왜 새로운 공격 표면이 되었는지, 2026년 도입이 늘고 있는 SSPM이 무엇인지, 그리고 실무에서 바로 적용할 수 있는 체크리스트까지 한 번에 정리합니다. IT 담당자든 보안 책임자든, 끝까지 읽으면 "이제 뭘 먼저 손봐야 하는지" 감이 잡힐 것입니다.
📌 바로가기 목차
 |
SaaS 보안 완전 정복 2026이라는 주제로 기업이 반드시 알아야 할 7가지 핵심 전략, SSPM, MFA, 권한관리, 데이터 보호와 규제 대응을 강조한 대표 썸네일 |
1. SaaS가 새로운 공격 표면이 된 이유
혹시 이런 생각 해보셨나요? "우리 회사는 방화벽도 있고 EDR도 깔았으니 보안은 어느 정도 됐다"는 안도감 말입니다. 솔직히 저도 몇 년 전까지는 비슷하게 생각했습니다.
그런데 실제 사고 사례를 들여다보면 출발점이 완전히 달라졌습니다. M365 계정 하나가 뚫리면 메일·문서·일정·내부 커뮤니케이션이 통째로 노출되고, GitHub 권한이 오남용되면 소스코드 유출은 물론 CI/CD 파이프라인까지 변조될 수 있습니다. Salesforce 계정 하나가 털리면 고객 정보와 영업 파이프라인이 그대로 빠져나갑니다.
2026년 들어 더 무서워진 건 공격 방식입니다. 'Starkiller' 같은 피싱 키트는 정상 로그인 페이지를 실시간으로 그대로 중계하는 방식(AitM)을 써서, MFA를 입력해도 그 세션 토큰 자체를 가로채 버립니다. 구글 맨디언트가 공개한 사례에서는 공격자가 직원에게 직접 전화를 걸어 "보안 정책이 바뀌었으니 인증을 다시 해달라"고 속이고, SSO라는 '공용 열쇠'를 통째로 빼앗아 연결된 모든 업무용 SaaS에 접근한 일도 있었습니다.
한 번 뚫리면 끝까지 뚫리는 구조, 이게 바로 SaaS 시대 보안의 가장 큰 함정입니다.
다음 섹션에서는 이런 공격 표면을 정면으로 다루기 위해 2026년 급부상한 SSPM이 무엇인지, 기존 보안 도구와 어떻게 다른지 비교해 보겠습니다.
2. SSPM이란 무엇인가 — 기존 보안과의 차이 비교
"방화벽도 있고 CASB도 있는데 왜 또 다른 솔루션이 필요하죠?" 컨설팅 현장에서 정말 자주 듣는 질문입니다. 답은 간단합니다. 기존 도구는 "GitHub 조직에 퍼블릭으로 열린 저장소가 있는가?", "Google Drive에서 만료되지 않은 외부 공유 링크가 몇 개 남아 있는가?" 같은 질문에 제대로 답하지 못합니다.
SSPM(SaaS Security Posture Management)은 Slack, M365, Salesforce, GitHub, Notion 같은 SaaS 앱에 API로 직접 연결해서 보안 설정·접근 권한·감사 로그를 상시로 수집·분석하고, 정책에 어긋나는 부분을 자동(또는 승인 후) 교정까지 수행하는 전용 보안 계층입니다. 한마디로 "SaaS 전용 CCTV + 자동 잠금장치"라고 보시면 이해가 쉽습니다.
| 구분 | 기존 보안 도구 (방화벽·CASB·EDR) | SSPM |
|---|---|---|
| 감시 대상 | 네트워크 트래픽, 엔드포인트 | SaaS 내부 설정·권한·공유 링크 |
| 탐지 방식 | 패턴·시그니처 기반 | 정책 엔진 기반 상시 비교 평가 |
| 대표 점검 항목 | 악성 트래픽, 비정상 접속 | SSO 미적용, MFA 예외 계정, 외부 공유 과다 |
| 대응 속도 | 사고 발생 후 분석 | 위반 탐지 즉시 자동/반자동 조치 |
여기서 질문 하나 드리겠습니다. 지금 우리 회사가 쓰는 SaaS 중에 "외부 공유 링크가 몇 개 살아있는지" 정확히 답할 수 있는 분이 계신가요? 답이 바로 안 나온다면, 다음 섹션의 흔한 실수 목록부터 확인해 보세요.
3. 기업들이 흔히 저지르는 SaaS 보안 실수
컨설팅 들어가서 SaaS 계정 목록을 받아볼 때마다 거의 비슷한 패턴이 반복됩니다. 의외로 큰 사고는 정교한 해킹 기술이 아니라 이런 기본적인 관리 누락에서 시작되는 경우가 훨씬 많습니다.
- 퇴사자 계정 방치: 퇴사 후에도 SaaS 계정이 살아있는 경우가 가장 흔한 실수입니다. SSO 기반 일괄 해지 프로세스 없이는 누락이 반복됩니다.
- MFA 예외 계정 방치: 임원·외부 협력사 계정은 "불편하다"는 이유로 MFA 예외 처리된 채 방치되는 경우가 많습니다. 가장 권한 높은 계정이 가장 약하게 보호되는 역설입니다.
- 외부 공유 링크 무제한 허용: Google Drive·Notion 등에서 "링크 있는 모든 사람"으로 공유된 문서가 만료 없이 누적되는 사례가 빈번합니다.
- OAuth 앱 승인 방치: 직원이 무심코 승인한 제3자 OAuth 앱이 메일·문서 접근 권한을 그대로 가진 채 수년간 방치되는 경우가 많습니다.
- 섀도우 IT: IT 부서 모르게 팀 단위로 가입한 SaaS가 누적되면서, 보안 점검 자체가 불가능한 영역이 생깁니다.
⚠️ 주의: 2026년 보고된 'Starkiller' 피싱 키트는 정상 로그인 화면을 실시간으로 그대로 보여주는 방식이라, MFA 입력 후 생성된 세션 토큰까지 가로챕니다. MFA를 켜두는 것만으로 안심해서는 안 되며, FIDO2 기반 피싱 저항형 인증으로 전환을 검토해야 합니다.
다음 섹션에서는 2026년 바뀐 규제 환경 — 망분리 예외와 CSAP 개편이 실무에 어떤 영향을 주는지 짚어보겠습니다.
 |
| 2026년 기업 SaaS 보안을 위해 SSPM, MFA, 권한관리, 외부 공유 링크 통제, 망분리 예외와 CSAP 대응 전략을 한눈에 정리한 여성 전문가 중심 인포그래픽 |
4. 2026년 망분리 예외·CSAP 개편이 바꾼 것들
"SaaS는 금융권에서는 못 쓰는 거 아니었나요?" 작년까지는 맞는 말이었습니다. 그런데 2026년 4월 20일부터 상황이 완전히 바뀌었습니다. 금융위원회와 금융감독원이 전자금융감독규정시행세칙을 개정하면서, 금융회사가 내부 업무망에서도 일정한 보안규율을 지키면 SaaS를 망분리 규제 예외로 활용할 수 있게 됐습니다.
물론 공짜로 풀린 건 아닙니다. 금융회사는 침해사고 대응기관 평가를 거친 SaaS만 써야 하고, 접속 단말기 보호대책을 수립해 반기 1회 평가하고 정보보호위원회에 보고해야 합니다. 같은 해 4월, 공공 클라우드 보안인증(CSAP) 체계도 개편되어 과기정통부와 국정원으로 나뉘었던 검증 창구가 국정원 중심으로 통합됐습니다. '인증의 늪'이라 불리던 중복 심사 구조가 사라지는 대신, 실질적인 보안 검증의 강도는 더 세진 셈입니다.
규제가 완화된 건 분명하지만, 그만큼 기업이 직접 책임져야 할 보안 통제 영역이 넓어졌다는 게 핵심입니다. 다음 섹션에서는 SaaS와 온프레미스 중 어디에 어떤 워크로드를 둬야 하는지, 보안 책임 관점에서 비교해 보겠습니다.
5. SaaS vs 온프레미스 — 워크로드별 보안 책임 비교
"그럼 이제 다 SaaS로 옮겨도 되는 거 아닌가요?" 이건 제가 가장 경계하는 질문입니다. 정답은 트렌드가 아니라 워크로드 특성에 있습니다. 코어 뱅킹이나 초저지연 트레이딩처럼 강력한 보안 통제가 필요한 핵심 자산은 여전히 온프레미스나 프라이빗 클라우드에 두고, 민첩성이 필요한 업무망은 제로 트러스트 기반 SaaS로 분리하는 하이브리드 구조가 현실적인 답입니다.
| 평가 항목 | 온프레미스 | SaaS |
|---|---|---|
| 통제력 | 자산을 직접 밀착 제어 가능 | 공급사 보안 정책에 의존 |
| 패치 속도 | 운영 역량 부족 시 지연 발생 | 공급사가 신속 패치, 단 설정 책임은 고객 |
| 주요 위험 | 인력 부족·패치 공백 | 공급망 공격, 섀도우 IT, 권한 오남용 |
| 적합 워크로드 | 코어 뱅킹, 초저지연 트레이딩 | 협업·사무관리·민첩성 요구 업무 |
| 필수 거버넌스 | 망분리·물리 보안 체계 | 제로 트러스트·SSPM·도입 통제 |
결론은 단순합니다 — 인프라 선택의 기준은 유행이 아니라 워크로드의 본질과 조직의 운영 성숙도여야 합니다.
6. 지금 바로 적용하는 SaaS 보안 체크리스트
의외로 충격적인 사례를 하나 짚고 시작하겠습니다. 2026년 3월, 자바스크립트 생태계에서 가장 널리 쓰이는 HTTP 라이브러리 axios의 npm 관리자 계정이 탈취돼 악성 버전이 배포됐고, 이 악성 코드는 설치 2시간 54분 만에야 제거됐습니다. 그 짧은 시간 동안 OpenAI의 macOS 앱 서명 인증서까지 영향을 받았습니다. SaaS와 오픈소스 패키지가 얽힌 공급망이 얼마나 빨리, 얼마나 광범위하게 무너질 수 있는지 보여주는 사례입니다.
- ☑ SaaS 전체 인벤토리 작성: 섀도우 IT까지 포함해 사용 중인 모든 SaaS와 연동 OAuth 앱을 전수 파악합니다.
- ☑ 퇴사자·휴면 계정 즉시 정리: SSO 연동으로 퇴사 처리 즉시 모든 SaaS 접근이 일괄 차단되도록 설계합니다.
- ☑ 피싱 저항형 인증 전환: 일반 MFA는 실시간 프록시 피싱에 뚫릴 수 있으므로 FIDO2 기반 인증으로 우선순위를 옮깁니다.
- ☑ 외부 공유 링크 만료 정책: Drive·Notion 등의 외부 공유 링크에 자동 만료 기한을 설정합니다.
- ☑ 패키지 의존성 모니터링: CI/CD에서 사용하는 npm·PyPI 패키지 버전을 고정하고, 신규 의존성 추가 시 검증 절차를 거칩니다.
- ☑ SSPM 도입 검토: 핵심 SaaS의 설정·권한·감사 로그를 상시로 점검할 전용 솔루션 도입을 검토합니다.
💡 실전 팁: 예산이 부족하다면 가장 먼저 손볼 항목은 퇴사자 계정 정리와 외부 공유 링크 점검입니다. 비용 없이 당장 시작할 수 있고, 실제 사고 사례에서 가장 자주 등장하는 시작점이기 때문입니다.
다음 FAQ에서 자주 헷갈리는 부분을 정리했어요.
 |
| 남성 보안 전문가가 SaaS 보안 대시보드를 분석하는 장면을 통해 자산 가시성, SSO·MFA, 권한관리, 감사로그, 컴플라이언스 대응을 실무 관점에서 표현한 인포그래픽 |
💻 실전 코드 — 바로 쓰는 SaaS 계정 보안 점검 자동화 스크립트
아래 코드는 SaaS 보안 점검에서 가장 먼저 손봐야 할 두 가지 — 퇴사자·휴면 계정 탐지와 npm 의존성 무결성 점검을 자동화하는 실전 스크립트입니다. Python으로 Google Workspace Admin SDK를 활용한 휴면 계정 탐지, Bash로 npm 패키지 버전 고정 점검을 다룹니다.
▶ 실전 코드 ① — Google Workspace 휴면·퇴사자 계정 탐지 스크립트
Google Workspace Admin SDK를 호출해 마지막 로그인 시점이 90일을 넘긴 계정과 보류(suspended) 상태가 아닌데도 활동이 없는 계정을 추려냅니다. 결과는 CSV로 저장해 IT 담당자가 바로 검토할 수 있게 구성했습니다.
# Google Workspace 휴면 계정·퇴사자 잔류 계정 탐지 스크립트
# 사전 준비: pip install google-api-python-client google-auth
from googleapiclient.discovery import build
from google.oauth2 import service_account
from datetime import datetime, timezone
import csv
# 서비스 계정 인증 정보는 환경변수 또는 비공개 파일 경로로 관리 (하드코딩 금지)
SERVICE_ACCOUNT_FILE = "YOUR_SERVICE_ACCOUNT_JSON_PATH"
ADMIN_EMAIL = "YOUR_ADMIN_EMAIL" # 위임받을 관리자 이메일
DORMANT_DAYS_THRESHOLD = 90
def get_admin_service():
# 도메인 와이드 위임으로 Admin SDK 클라이언트 생성
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE,
scopes=["https://www.googleapis.com/auth/admin.directory.user.readonly"],
subject=ADMIN_EMAIL
)
return build("admin", "directory_v1", credentials=credentials)
def find_dormant_accounts(service, domain="YOUR_DOMAIN.com"):
dormant_users = []
page_token = None
while True:
# 사용자 목록을 페이지 단위로 조회
response = service.users().list(
domain=domain,
pageToken=page_token,
maxResults=100
).execute()
for user in response.get("users", []):
last_login = user.get("lastLoginTime")
if not last_login:
continue
last_login_dt = datetime.fromisoformat(last_login.replace("Z", "+00:00"))
idle_days = (datetime.now(timezone.utc) - last_login_dt).days
# 90일 이상 미로그인 + 정지 상태가 아닌 계정만 위험으로 분류
if idle_days >= DORMANT_DAYS_THRESHOLD and not user.get("suspended"):
dormant_users.append({
"email": user["primaryEmail"],
"idle_days": idle_days,
"is_admin": user.get("isAdmin", False)
})
page_token = response.get("nextPageToken")
if not page_token:
break
return dormant_users
def export_to_csv(dormant_users, filename="dormant_accounts_report.csv"):
# 보안 담당자가 바로 확인할 수 있는 CSV 리포트 생성
with open(filename, "w", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=["email", "idle_days", "is_admin"])
writer.writeheader()
writer.writerows(dormant_users)
print(f"리포트 생성 완료: {filename} (총 {len(dormant_users)}건)")
if __name__ == "__main__":
service = get_admin_service()
dormant = find_dormant_accounts(service)
export_to_csv(dormant)
이 스크립트는 매주 1회 크론으로 돌려두면, 관리자 권한을 가진 휴면 계정부터 우선 알림이 가도록 확장할 수 있습니다. 관리자 계정(is_admin: true)이 90일 넘게 로그인하지 않았다면 즉시 비활성화를 검토해야 합니다. 도메인 와이드 위임 설정은 Google Workspace 관리 콘솔에서 별도로 승인해야 동작합니다.
▶ 실전 코드 ② — npm 패키지 무결성·버전 고정 점검 스크립트
2026년 axios·샤이훌루드 사례처럼 신뢰하던 패키지의 관리자 계정이 탈취되면 악성 버전이 그대로 배포됩니다. 아래 Bash 스크립트는 package-lock.json의 버전 고정 여부와 알려진 위험 패키지 목록을 대조해 CI 파이프라인에서 빌드를 차단하는 게이트 역할을 합니다.
#!/bin/bash
# npm 패키지 무결성 점검 스크립트 — CI/CD 파이프라인 게이트용
# 사용법: ./check_npm_integrity.sh
set -euo pipefail
LOCK_FILE="package-lock.json"
# 알려진 침해 패키지/버전 목록 — 보안 공지 발표 시 즉시 갱신 필요
DENYLIST=(
"axios@1.14.1"
"axios@0.30.4"
"plain-crypto-js"
"easy-day-js"
)
echo "[1/3] package-lock.json 존재 여부 확인 중..."
if [ ! -f "$LOCK_FILE" ]; then
echo "오류: $LOCK_FILE 이 없습니다. 버전 고정 없이 배포하면 공급망 공격에 노출됩니다." >&2
exit 1
fi
echo "[2/3] 알려진 위험 패키지 대조 중..."
FOUND_RISK=0
for entry in "${DENYLIST[@]}"; do
if grep -q "$entry" "$LOCK_FILE"; then
echo " ⚠ 위험 패키지 발견: $entry"
FOUND_RISK=1
fi
done
if [ "$FOUND_RISK" -eq 1 ]; then
echo "빌드 중단: 위험 패키지가 감지되어 배포를 차단합니다." >&2
exit 1
fi
echo "[3/3] npm audit 실행 중..."
# 알려진 취약점(CVE) 기준 고위험만 차단, 경고는 로그로만 기록
if ! npm audit --audit-level=high; then
echo "빌드 중단: npm audit에서 고위험 취약점이 발견되었습니다." >&2
exit 1
fi
echo "✅ 무결성 점검 통과 — 위험 패키지 없음, 고위험 취약점 없음"
이 스크립트는 GitHub Actions나 GitLab CI의 빌드 단계 맨 앞에 배치하면, 위험 패키지가 섞인 코드가 운영 환경까지 가는 것을 사전에 막아줍니다. DENYLIST는 보안 공지가 나올 때마다 즉시 갱신해야 실효성이 유지됩니다. npm audit --audit-level=high 옵션으로 너무 잦은 차단을 줄이면서도 핵심 위협은 놓치지 않도록 균형을 잡았습니다.
💡 실전 팁: 두 스크립트 모두 단독으로는 한계가 있습니다. 휴면 계정 탐지는 SSO 로그와 연동해야 정확도가 올라가고, npm 점검은 SBOM(소프트웨어 자재명세서) 관리와 함께해야 전이 의존성까지 커버됩니다. SSPM 솔루션을 도입한다면 두 가지 점검을 API 연동으로 자동화할 수 있습니다.
 |
| SaaS 보안의 핵심 요소인 클라우드 보안, MFA, SSPM, 접근제어, 외부 공유 통제를 직관적으로 표현한 프리미엄 여성 대표 썸네일 |
7. 자주 묻는 질문 (FAQ)
예산이 부족하다면 SSPM 도입 전에 6번 체크리스트의 퇴사자 계정 정리, 외부 공유 링크 점검부터 무료로 시작할 수 있습니다. SaaS 사용량이 늘수록 사각지대도 같이 늘기 때문에 규모가 작다고 안전한 건 아닙니다.
네, 가능합니다. 'Starkiller' 같은 실시간 프록시형 피싱 키트는 정상 로그인 화면을 그대로 보여주면서 MFA 입력 직후 발급된 세션 토큰까지 가로챕니다. 1번 섹션에서 다룬 것처럼 FIDO2 기반 피싱 저항형 인증으로의 전환이 필요한 이유입니다.
패키지 버전을 고정하고, 신규 의존성이 추가될 때마다 검증 절차를 거치는 것이 1차 방어선입니다. 실전 코드 섹션의 점검 스크립트처럼 CI/CD 파이프라인 단계에서 알려진 위험 패키지를 자동 차단하는 게이트를 두는 방법을 권장합니다.
직접 적용 대상은 아니지만, 금융권에 요구되는 보안 통제 수준(SaaS 평가, 단말 보호대책, 반기 보고)은 일반 기업의 SaaS 거버넌스 기준으로 참고할 가치가 충분합니다. 4번 섹션에서 더 자세히 다뤘습니다.
SSO와 SSPM 두 가지가 출발점입니다. SSO는 퇴사자·휴면 계정 일괄 차단의 기반이 되고, SSPM은 설정·권한·공유 링크 같은 기존 도구가 놓치는 사각지대를 채워줍니다. 더 궁금한 점은 댓글로 남겨주세요!
8. 마무리 요약
✅ SaaS 보안 — 인프라가 된 순간부터 책임도 시작됩니다
SaaS는 더 이상 부가적인 도구가 아니라 기업 인프라의 한 축이 되었습니다. M365·GitHub·Salesforce 계정 하나가 침해되면 메일부터 소스코드, 고객 정보까지 한꺼번에 위험에 노출되고, axios 사태처럼 신뢰하던 오픈소스 패키지 하나가 공급망 전체를 흔들 수도 있습니다.
2026년 망분리 규제 예외와 CSAP 체계 개편은 SaaS 활용의 문턱을 낮췄지만, 그만큼 기업이 직접 책임져야 할 보안 통제 영역도 함께 넓어졌습니다. 퇴사자 계정 정리, 피싱 저항형 인증 전환, 패키지 무결성 점검이라는 기본부터 다시 점검하는 조직이 결국 사고를 피해갑니다.
오늘 이 글을 읽으셨다면, 지금 당장 한 가지만 해보세요 — 우리 회사 SaaS 중 퇴사자 계정이 살아있는 곳이 있는지 한 번만 확인하는 것. 10분이면 충분하고, 실제 사고의 시작점은 대부분 이 지점이었습니다.
여러분의 조직은 지금 SaaS 보안 체크리스트 중 몇 개나 갖춰져 있으신가요? 댓글로 현황을 공유해 주시면 같이 고민해 드리겠습니다. 다음 포스팅에서는 SSPM 솔루션 실전 비교 — 무엇을 기준으로 골라야 하는가를 다룰 예정이니 기대해 주세요!
댓글
댓글 쓰기