무료 상담
SECURITY QUICK CHECK

공개 설정의 약점을 찾아, 다음에 확인해야 할 위험까지 정리합니다.

도메인의 공개 정보에서 HTTPS, DNS, 보안 헤더 등 기본 설정을 짧은 시간에 확인합니다. 나아가 공개 설정만으로는 발견할 수 없는 인증정보·토큰·클라우드·단말·백업 위험도 이해하기 쉬운 그림으로 정리합니다.

이 점검은 공개 정보를 이용한 비침투형 간이 확인입니다. 내부 침투 테스트, 비밀번호 시도, 포트 스캔, 애플리케이션 상세 취약점 진단은 수행하지 않습니다.

무료로 도메인 점검 보안 개선 상담
공개 정보 중심 확인 비밀번호·비밀정보 입력 불필요 침투·무차별 대입 시도 없음 결과는 안전 보증이 아닌 개선의 입구
제로 트러스트 설계

"사내라서 안전"을 버리다 — 제로 트러스트라는 방어 방식

외부에서 보이는 입구의 상태는 이 간이 진단으로 확인할 수 있습니다. 그 이후는 사내·클라우드·재택을 불문하고 접근할 때마다 본인과 단말을 검증하는 '제로 트러스트'로 보호합니다.

  • ID·다요소 인증

    Microsoft Entra로 본인 확인을 철저히. 비밀번호 의존을 벗어나 다요소 인증과 조건부 액세스로 부정 로그인을 막습니다.

  • 디바이스 상태 검증

    회사가 파악·관리하는 단말만 신뢰. OS 업데이트와 멀웨어 대책 상태를 확인하고 위험한 단말의 접근을 차단합니다.

  • 최소 권한과 가시화

    필요한 사람에게 필요한 범위만 허용. 누가 무엇에 접근했는지 기록·가시화하여 이상을 즉시 탐지합니다.

생성형 AI나 외부 연계(MCP·API)가 늘어도, 경계가 아닌 '검증'으로 지키기 때문에 확장해도 구멍이 벌어지기 어려운 것이 장점입니다.

제로 트러스트 설계 상담하기

공격자가 노리는 것은 비밀번호만이 아닙니다

인증 성공 후 발급되는 쿠키·액세스 토큰, 앱·CI/CD가 가진 비밀정보, 클라우드 워크로드의 ID, 인증 기반의 서명 키도 공격 대상이 됩니다. 따라서 입구 인증뿐 아니라 '인증정보가 어디에 존재하고 어디에서 유출되는가'를 전체적으로 생각해야 합니다.

이미지를 클릭하면 확대됩니다

URL·로그로의 혼입

URL에 액세스 토큰을 포함하면 브라우저 기록, Referer, 프록시, APM, 액세스 로그 등에 남습니다.

앱／API 서버 침해

서버에 침입당하면 메모리, 캐시, 데이터베이스, 설정 파일 등에서 토큰·비밀정보가 탈취될 수 있습니다.

CI/CD·소스 관리

API 키, 비밀번호, 토큰이 환경 변수, 빌드 로그, 설정 파일, 소스 코드에 실수로 기록될 수 있습니다.

인증정보는 한 곳에만 존재하지 않습니다. URL, 브라우저, 서버, 클라우드, 개발 파이프라인, 단말 각각에서 '보이지 않게·남기지 않게·퍼지지 않게' 설계해야 합니다.

공격 경로별 상세 해설

대표적인 공격을 5개 카테고리로 정리했습니다. 각 이미지는 클릭 또는 탭으로 확대할 수 있습니다.

인증과 세션

피싱／중계형 공격

가짜 메일·링크로 사용자를 가짜 로그인 화면으로 유도합니다. 중계 서버가 사용자와 정규 서비스 사이에 끼어 ID·비밀번호·MFA 조작을 정규 서비스로 중계하기도 합니다.

공격 흐름과 대책 보기
공격의 흐름

정규 서비스에서 로그인이 성공하면, 성립된 세션 쿠키·인증 토큰을 공격자가 획득해 로그인된 상태를 재사용할 수 있습니다.

예상되는 영향

MFA를 도입했더라도 방식에 따라 중계형 피싱의 영향을 받아 로그인된 세션이 탈취될 수 있습니다.

우선 대책
  • 관리자·중요 사용자부터 패스키／FIDO2로 이전
  • 레거시 인증 비활성화
  • 조건부 액세스 적용
  • 준수 단말·관리 대상 단말 요구
  • 의심스러운 로그인·세션 모니터링
  • 세션 무효화 절차 준비
Quick Check로 알 수 있는 범위

공개 정보로는 메일·로그인 화면의 내용까지는 확인할 수 없습니다. HTTPS·HSTS 유무 등 기본 설정 일부만 확인할 수 있습니다.

Quick Check로는 알 수 없는 범위

MFA 방식, 조건부 액세스, 세션 보호, 피싱 저항 인증 도입 상태는 확인할 수 없습니다.

주의 'FIDO2만 도입하면 모든 공격을 막을 수 있다'고 생각하지 마세요. 단말 자체가 침해되거나 로그인 후 세션 탈취에는 별도 방어가 필요합니다.

인증 기반·서명 키 침해

공격자가 인증 기반, 서명 키, 인증서, 키 관리 서버, 관리자 계정 등에 침입합니다.

공격 흐름과 대책 보기
공격의 흐름

서명용 비밀 키를 취득하거나 부정 이용하면 진짜 인증 기반이 발급한 것처럼 보이는 JWT·토큰을 생성해 API·업무 앱·클라우드 리소스에 접근할 수 있습니다.

예상되는 영향

서명 키는 인증 신뢰의 토대입니다. 침해되면 비밀번호를 훔치지 않고도 정규처럼 보이는 토큰을 만들 수 있습니다.

우선 대책
  • 고가치 서명 키를 HSM 또는 Managed HSM으로 보호
  • 제어 플레인과 데이터 플레인 권한 분리
  • 인증 기반 관리·키 관리·감사 역할 분리
  • PIM/JIT로 관리 권한 일시화
  • 정기적인 키 로테이션
  • 키 무효화·인증서 갱신·토큰 무효화 긴급 절차
  • 운영 키를 개발 환경에 반입하지 않기
Quick Check로 알 수 있는 범위

인증 기반이나 키 관리 상태는 공개 정보로 확인할 수 없습니다.

Quick Check로는 알 수 없는 범위

서명 키 보호 방식(HSM 등), 권한 분리, 키 로테이션, 감사 로그, 긴급 무효화 절차는 확인할 수 없습니다.

주의 HSM만으로 관리자 계정 침해나 부정 키 이용을 모두 막을 수는 없습니다. 관리 분리와 모니터링을 조합하세요.

웹 앱과 로그

XSS·악성 브라우저 확장 프로그램

웹 앱에 악성 JavaScript가 혼입되어 실행되면 localStorage, sessionStorage, 화면 입력, 참조 가능한 쿠키 등을 읽어 외부로 전송될 수 있습니다.

공격 흐름과 대책 보기
공격의 흐름

사용자가 설치한 악성 확장 프로그램도 페이지 내용, 폼 정보, 쿠키, 토큰 등에 접근할 수 있습니다.

예상되는 영향

로그인한 사용자로부터 인증 토큰·입력 정보가 유출되어 사칭이나 정보 유출로 이어질 수 있습니다.

우선 대책
  • Razor 자동 인코딩을 비활성화하지 않기
  • Html.Raw를 함부로 사용하지 않기
  • innerHTML·document.write 피하기
  • HTML 허용 시 신뢰할 수 있는 새니타이저 사용
  • CSP를 nonce 또는 hash 기반으로 설정
  • 쿠키에 HttpOnly·Secure·적절한 SameSite 설정
  • 인증 토큰을 localStorage에 함부로 저장하지 않기
  • 기업 단말에서는 브라우저 확장 프로그램을 허용제로
Quick Check로 알 수 있는 범위

Content-Security-Policy·X-Content-Type-Options 헤더 유무는 확인할 수 있습니다(다층 방어의 일부).

Quick Check로는 알 수 없는 범위

실제 XSS 존재 여부, 쿠키 속성(HttpOnly / Secure / SameSite), 토큰 저장 위치, 확장 프로그램 관리 상태는 확인할 수 없습니다.

주의 CSP는 중요하지만 XSS 대책의 중심으로 삼지 마세요. 기본은 입력값 검증, 출력 위치에 맞는 인코딩, 안전한 DOM API 사용입니다. HttpOnly 쿠키가 XSS 자체를 고치지는 않습니다.

URL·로그로의 비밀정보 혼입

로그인 후 URL에 access_token 등 비밀정보를 포함하면 브라우저 기록, Referer, 리버스 프록시, APM, 웹 서버 액세스 로그 등에 남을 수 있습니다.

공격 흐름과 대책 보기
공격의 흐름

로그에 남은 토큰, 인가 코드, 세션 ID, 사용자 식별자 등이 열람·전송되어 악용될 수 있습니다.

예상되는 영향

URL은 많은 시스템에 기록됩니다. POST 본문이라도 APM·디버그 로그에 기록될 수 있어 'POST면 무조건 안전'하다고 할 수 없습니다.

우선 대책
  • URL에 비밀정보를 넣지 않기
  • 로그 수집 전에 토큰·쿠키 마스킹
  • APM·프록시·WAF·액세스 로그 설정 확인
  • Referrer-Policy 설정
  • 토큰 단명화
  • 불필요한 쿼리 문자열을 분석 기반에 보내지 않기
Quick Check로 알 수 있는 범위

URL 설계나 로그 내용은 외부에서 확인할 수 없습니다. 기본 보안 헤더 유무만 확인할 수 있습니다.

Quick Check로는 알 수 없는 범위

URL의 비밀정보 혼입, 로그 마스킹 상태, APM·프록시 설정, Referrer-Policy 내용은 확인할 수 없습니다.

클라우드와 서버

앱／API 서버 침해

공격자가 취약점, 설정 불비, 부정 접근 등을 이용해 앱 또는 API 서버에 침입하여 내부를 탐색합니다.

공격 흐름과 대책 보기
공격의 흐름

프로세스 메모리, 캐시, 데이터베이스, 환경 변수, 설정 파일, 임시 파일, 로그 등에서 토큰·쿠키·API 키·연결 문자열을 취득해 다른 시스템에 부정 접근합니다.

예상되는 영향

앱이 정규로 사용하는 인증정보도 공격자에게 보이므로, '침입시키지 않는다'뿐 아니라 침입당해도 비밀을 노출하지 않고 권한을 확장하지 않으며 유출을 탐지하는 설계가 필요합니다.

우선 대책
  • 비밀정보를 소스·설정 파일에 직접 저장하지 않기
  • Azure Key Vault 등 비밀 관리 기반 사용
  • Managed Identity로 고정 자격증명 축소
  • 앱·DB·관리계 분리
  • 최소 권한 RBAC
  • EDR·로그 모니터링·이상 탐지
  • 침해 시 시크릿 로테이션 절차 준비
Quick Check로 알 수 있는 범위

서버 내부 상태는 공개 정보로 확인할 수 없습니다. 외부에 공개된 HTTPS·헤더 일부만 확인할 수 있습니다.

Quick Check로는 알 수 없는 범위

비밀정보 관리 방법, 권한 설계, 패치 적용, EDR·모니터링 도입 상태, 워크로드 분리는 확인할 수 없습니다.

클라우드 워크로드 침해와 Managed Identity 악용

공격자가 웹 앱, VM, App Service, 컨테이너 등에 침입해 내부 메타데이터 서비스·인증 엔드포인트에 접근합니다.

공격 흐름과 대책 보기
공격의 흐름

워크로드에 할당된 Managed Identity 등의 임시 액세스 토큰을 취득해 앱으로 위장하여 Azure 리소스에 접근합니다.

예상되는 영향

Managed Identity 자체는 유효한 구조지만, 워크로드가 침해되고 해당 ID에 과도한 권한이 부여되어 있으면 공격자도 같은 권한을 사용할 수 있습니다.

우선 대책
  • Managed Identity에도 최소 권한 적용
  • 구독 전체 Contributor 등을 함부로 부여하지 않기
  • 무관한 여러 워크로드에서 같은 ID를 공유하지 않기
  • 외부 입력으로 임의 URL에 접속시키지 않기
  • URL 허용 목록과 이름 해석 후 IP 검증 실시
  • 프라이빗·루프백·링크로컬 대상 거부
  • 리다이렉트 대상도 재검증
  • 네트워크 분리와 Private Endpoint 검토
Quick Check로 알 수 있는 범위

클라우드 내부의 권한·네트워크 설계는 공개 정보로 확인할 수 없습니다.

Quick Check로는 알 수 없는 범위

Managed Identity 권한 설계, SSRF 대책, 네트워크 분리, 메타데이터 서비스 보호 상태는 확인할 수 없습니다.

주의 SSRF 대책을 단순 문자열 검사만으로 구현하지 마세요. 이름 해석 후 IP 검증과 리다이렉트마다 재검증이 필요합니다.

클라우드 전체의 취약점과 공격 경로를 지속적으로 확인

생성 AI와 공격 자동화로 취약점 발견부터 공격 개시까지의 시간이 짧아지는 환경을 배경으로, Microsoft Defender for Cloud로 클라우드 보안 상태를 지속적으로 평가하는 개념입니다.

공격 흐름과 대책 보기
공격의 흐름

자산·구성·취약점의 지속 평가, 인터넷 공개 자산 파악, ID·네트워크·데이터를 연결한 공격 경로 분석, Azure·AWS·GCP를 포함한 멀티클라우드 관리를 수행합니다.

예상되는 영향

모든 문제를 같은 우선순위로 고치는 것이 아니라, 외부 공개·권한·취약점·데이터 중요도·실제 공격 경로를 조합해 우선순위를 매깁니다.

우선 대책
  • 대상 자산과 연결된 환경 목록화
  • Defender for Cloud 커버리지 확인
  • 보안 권장 사항의 담당자·기한 설정
  • 공격 경로에서 고위험 항목 우선
  • 인터넷 공개 자산 정기 확인
  • 예외·면제·미대응 사유 기록
  • 개선 상황을 경영·정보시스템·개발이 공유
Quick Check로 알 수 있는 범위

이 간이 점검으로 알 수 있는 것은 공개 자산의 일부(HTTPS·DNS 등)뿐입니다.

Quick Check로는 알 수 없는 범위

클라우드 구성의 포괄적 평가, 공격 경로 분석, Defender 커버리지, 우선순위 부여는 확인할 수 없습니다.

주의 제품 기능·명칭은 변경될 수 있으므로 Microsoft Learn 최신 정보와 모순되지 않는 범위에서 확인하세요.

단말과 관리자

사용 단말의 멀웨어

업무 앱·클라우드 서비스에 로그인한 단말이 멀웨어에 침해되는 흐름을 나타냅니다.

공격 흐름과 대책 보기
공격의 흐름

침해된 단말에서 브라우저 저장 ID·비밀번호, 실행 중 프로세스 메모리, 쿠키·인증 토큰, 캐시·임시 파일, 화면·입력 정보가 탈취될 수 있습니다.

예상되는 영향

인증이 강력해도 로그인에 쓰는 단말 자체가 침해되면 로그인 후 인증정보가 탈취될 수 있습니다. 중요 조작·관리자 작업에서는 단말 안전성을 인증 조건의 일부로 다뤄야 합니다.

우선 대책
  • EDR 도입과 온보딩 누락 확인
  • 공격 표면 축소 규칙
  • 조건부 액세스로 관리 대상·준수 단말 요구
  • 로컬 관리자 권한 축소
  • 애플리케이션 제어
  • 관리자 전용 단말(PAW／SAW) 사용
  • 감염 단말 격리와 토큰 무효화 절차
Quick Check로 알 수 있는 범위

단말 상태는 공개 정보로 전혀 확인할 수 없습니다.

Quick Check로는 알 수 없는 범위

EDR 도입, 단말 준수, 조건부 액세스, 로컬 관리자 권한, 앱 제어 상태는 확인할 수 없습니다.

복구와 백업

침해 후에도 복구 가능한 이뮤터블 백업

Azure와 온프레미스 환경에서 백업을 보호 영역에 저장하고, 중앙 Immutable Vault에서 보존 기간 동안 삭제·변조할 수 없게 하는 개념입니다.

공격 흐름과 대책 보기
공격의 흐름

공격자나 침해된 관리자가 백업 삭제, 복구 지점 삭제, 보존 기간 단축, 보호 중지를 시도해도 다층 방어로 중요 조작을 보호합니다.

예상되는 영향

랜섬웨어 대책에서는 운영 데이터를 지키는 것뿐 아니라 공격자·침해된 관리자로부터 백업 자체를 지켜야 합니다.

우선 대책
  • 지원하는 Vault에서 이뮤터빌리티 활성화
  • 운영 확정 후 Locked 상태 검토
  • Soft Delete 활성화
  • Resource Guard와 MUA(Multi-user Authorization) 구성
  • 백업 관리자와 보안 관리자 분리
  • Resource Guard를 별도 구독 또는 별도 테넌트로 분리
  • 복원 테스트 정기 실시
  • RPO·RTO·보존 기간을 업무 요건에서 설정
Quick Check로 알 수 있는 범위

백업·복구 설계는 공개 정보로 확인할 수 없습니다.

Quick Check로는 알 수 없는 범위

Vault 설정, 이뮤터빌리티, Soft Delete, MUA, 관리 분리, 복원 테스트 상태는 확인할 수 없습니다.

주의 이미지는 개념도입니다. 모든 Azure DB나 온프레미스 제품이 설정만으로 같은 방식으로 보호되는 것은 아닙니다. 지원 워크로드·Vault 종류·리전·방식에 따라 사용 가능한 기능이 다르므로 실제 환경에서 확인이 필요합니다.

무엇부터 고쳐야 할지 모를 때는 5단계로 정리합니다

모든 것을 한 번에 대응할 필요는 없습니다. 영향이 크고 악용되기 쉬운 곳부터 순서대로 정비하는 개념입니다.

  1. STEP 1 외부에 공개한 입구를 지킨다

    • HTTPS 상시화와 HTTP→HTTPS 리다이렉트
    • TLS 인증서 유효기간 관리
    • HSTS 등 기본 보안 헤더 부여
    • 불필요한 공개 포트·관리 화면 폐쇄

  2. STEP 2 인증과 계정을 강화한다

    • 피싱에 강한 다요소 인증
    • 조건부 액세스로 단말·장소·위험 고려
    • 관리자 권한 최소화와 PIM／JIT
    • 퇴직자·불필요 계정 정리

  3. STEP 3 앱과 데이터의 취급을 재검토한다

    • 입력값 검증과 출력 이스케이프(XSS 대책)
    • 비밀 정보를 URL·로그에 남기지 않기
    • 시크릿을 Key Vault 등으로 관리
    • 최소 권한으로 API·서비스 연계

  4. STEP 4 클라우드와 단말을 지속적으로 감시한다

    • 클라우드 구성의 지속 평가와 공개 자산 파악
    • EDR 도입과 단말 준수 상태
    • 로그 집약과 이상 탐지
    • 인시던트 대응 절차 정비

  5. STEP 5 침해되어도 복구할 수 있는 대비를 갖춘다

    • 변조·삭제에 강한 이뮤터블 백업
    • 백업 관리자와 운영 관리자 분리
    • 정기적인 복원 테스트
    • RPO·RTO와 보존 기간을 업무 요건에서 설정

이 순서는 어디까지나 정리의 기준입니다. 실제 우선순위는 공개 범위, 다루는 데이터의 중요도, 업무 영향에 따라 달라집니다.

점검 결과를 실제 개선 계획으로

간이 점검은 어디까지나 입구입니다. 여기서부터는 환경과 운영에 맞춰 구체적인 개선 내용을 함께 정리합니다.

웹 공개 설정 리뷰

  • HTTPS·TLS·보안 헤더 점검
  • 리다이렉트·쿠키 속성 확인
  • 불필요한 공개 자산 도출
  • 개선 내용 구체화와 우선순위 부여

Entra ID·인증 리뷰

  • 다요소 인증과 조건부 액세스 설계
  • 관리자 권한과 PIM／JIT 재검토
  • 게스트·외부 연계 권한 정리
  • 로그인 위험 대응 방침

Azure·멀티클라우드 리뷰

  • 클라우드 구성 지속 평가의 개념
  • 공개 자산과 공격 경로 파악
  • 권한·네트워크·데이터 보호 재검토
  • 우선순위를 매긴 개선 로드맵

앱·개발 공정 리뷰

  • 입력 검증·출력 이스케이프 설계
  • 시크릿 관리와 설정 정보 취급
  • 의존 관계·공급망 확인
  • 개발 공정에 보안 내재화

랜섬웨어·복구 설계

  • 이뮤터블 백업 설계
  • 백업 관리와 권한 분리
  • 복원 테스트와 복구 절차 정비
  • RPO·RTO와 보존 방침 설정
점검 결과에 대해 상담하기 30분 보안 상담 신청

리뷰 내용은 환경과 규모에 맞춰 조정합니다. 우선 현황과 우려되는 점을 알려주세요.

간이 점검으로 확인할 수 있는 범위

이 점검으로 확인할 수 있는 것

현재 백엔드 구현이 실제로 확인하는 항목만 표시합니다.

  • HTTPS로 공개되어 있는지
  • TLS 인증서 유효기간
  • 주요 보안 헤더(HSTS / CSP / X-Content-Type-Options / X-Frame-Options) 유무
  • HTTP에서 HTTPS로의 유도(리다이렉트)
  • DNS 공개 레코드(A / AAAA)
  • 메일 인증 공개 설정(SPF / DMARC)

이 점검만으로는 확인할 수 없는 것

  • 앱 내부의 인가 결함
  • SQL 인젝션·XSS 실제 검증
  • Entra ID·조건부 액세스 설정
  • 쿠키·토큰 저장 방식
  • 소스 코드·CI/CD 내 비밀정보
  • 서버 메모리·캐시 내 정보
  • Managed Identity 권한 설계
  • 사용 단말의 멀웨어 감염
  • 서명 키·인증서 관리 상태
  • 백업의 삭제 저항성
  • 내부 네트워크·관리 화면 설정

공개 설정 확인은 '입구'입니다. 중요 시스템에서는 앱, ID, 클라우드, 단말, 백업을 조합하여 평가해야 합니다.

먼저 공개된 설정을 확인

웹사이트 외부에서 확인할 수 있는 설정에는 공격을 막기 위한 중요한 단서가 있습니다. 다만 공개 설정에 문제가 없다는 것과 시스템 전체가 안전하다는 것은 같지 않습니다.

example.com 형식으로 입력 http://, https://, 경로는 입력 불필요 자사 또는 확인 권한이 있는 도메인을 입력하세요

자주 묻는 질문

이 간이 점검만으로 자사 보안이 괜찮다고 할 수 있나요?

아니요. 이 진단은 공개된 도메인의 입구 부분(HTTPS·DNS·메일 인증 등)을 확인하는 것입니다. 인증 기반, 클라우드 구성, 단말, 사내 시스템, 백업 등은 포함되지 않습니다. 안전을 보증하는 것이 아니라 첫 알아차림을 위한 도구로 생각해 주세요.

입력한 도메인은 저장되나요?

이 도구는 입력된 도메인을 데이터베이스 등에 영구적으로 저장하지 않습니다. 진단을 위해 서버에서 대상 도메인에 일시적으로 접속하고 결과를 표시하는 데만 사용합니다. 결과 화면 URL에도 도메인은 포함되지 않습니다.

자사가 관리하지 않는 도메인을 점검해도 되나요?

이 도구는 공개 정보 범위에서 외형적 확인을 하지만, 원칙적으로 본인이 관리하거나 허가받은 도메인에 사용하세요. 타인의 도메인에 대한 과도한 조사나 공격적 행위는 의도하지 않습니다.

결과가 '문제 없음'이었던 항목은 앞으로도 안전한가요?

그 시점의 외형적 확인 결과에 불과합니다. 인증서 기한, 설정 변경, 새로운 취약점 등으로 상황은 바뀝니다. 정기적인 확인과 지속적인 감시·운영을 전제로 생각해 주세요.

게재된 그림이나 제품명을 그대로 자사에 적용해도 되나요?

그림은 개념을 전달하기 위한 개념도입니다. 실제로 사용할 수 있는 기능·설정은 대상 워크로드·계약·리전·구성에 따라 다릅니다. 도입 전에 최신 공식 정보와 자신의 환경에서 확인해 주세요.

개선을 상담하고 싶을 때 무엇부터 시작하면 되나요?

우선 이 페이지의 간이 점검 결과와 우려되는 점을 알려주세요. 공개 설정·인증·클라우드·앱·복구 중 어디부터 착수할지 현황에 맞춰 함께 정리합니다. 문의 폼이나 상담 예약으로 편하게 연락 주세요.