IT 환경에서 자주 오해하거나 방치되는 “ 잘못된 통념”에 대한 각 항목마다 보안 관점에서 고려해야 할 점검 포인트와 실무적인 활용사례를 통해 조직 내 보안 수준을 한층 높이는 데 도움이 될 수 있습니다.
1. "우리는 해킹 대상이 아니다."
- 중소기업, 비영리 단체, 개인 등 규모나 성격이 작거나 특별하지 않다고 여겨 스스로 해커의 관심 대상에서 벗어난다고 생각하는 경우가 많음
문제점
- 랜섬웨어: 무차별 공격 대상 중 하나로 누구든 걸릴 수 있음
- 공급망 공격: 협력사나 하청사로 침투하여 최종 타깃을 공격하는 방식 증가
- 봇넷용 좀비화: 취약한 시스템은 악성코드에 감염되어 다른 공격을 위한 중계점(Proxy)로 악용될 수 있음
개선 방안
- 위험 기반 접근(Risk-based Approach) 도입
- 자산 식별 → 위협 및 취약점 평가 → 위험 분석 후 우선순위에 따라 보안 대책 적용
- 자산 목록화 및 정기적 점검
- 서버, PC, 네트워크 장비, IoT 기기 등 모두 식별 후 보안 업데이트, 취약점 점검
- 기본 보안 조치 강화
- 패치 관리, 백업, 네트워크 모니터링 등 필수 항목 정기 수행
점검 포인트
- ○○ 서버나 장비가 중단되면 업무에 미치는 영향은?
- 중요한 자산(데이터, 시스템)은 어떤 취약점이 있으며 어떻게 보호하고 있는가?
- 보안 인식 교육(피싱 메일 테스트, 보안 정책 안내 등)은 주기적으로 이루어지고 있는가?
2. "기본 설정이면 괜찮다."
- 기본 설정(Default Setting)은 제조사 또는 솔루션 제공사가 안정적으로 설정해놓은 것이라 가정
- 별도 설정이 귀찮거나 어려움을 느껴 그대로 사용
문제점
- 디폴트 비밀번호, 기본 포트, 기본 권한 등이 이미 공개되어 있어 누구나 쉽게 접근 가능
- IoT 기기, 클라우드 서비스 등에서 특히 취약 (공개된 포트 스캔 공격이 빈번)
개선 방안
- Secure Configuration Guide 활용
- 각 벤더나 국제 표준(예: CIS 벤치마크)에서 제공하는 권고사항을 따라 설정
- 초기 설정 시 강력한 비밀번호 생성 및 필요 없는 기능 비활성화
- 예시:
sudo passwd root→ 복잡한 비밀번호 설정 - 사용하지 않는 서비스(port)를 차단하거나 비활성화
- 예시:
- CIS 벤치마크 등 표준 보안 가이드 준수
- Linux, Windows, 데이터베이스 등 각각의 CIS Benchmarks 문서 참조
점검 포인트
- 디폴트 포트나 계정이 그대로 사용 중인 시스템이 있는가?
- 서비스 오픈 전에 CIS, NIST 등 표준 문서를 기준으로 설정을 검토했는가?
- 설정 변경 내역이 변경관리(Change Management) 시스템에 기록되는가?
3. "보안 솔루션만 있으면 안전하다."
- 보안 소프트웨어(백신, 방화벽, IDS/IPS 등)를 설치하면 모든 위협이 자동으로 차단된다고 믿는 경우
- 보안 솔루션의 도입 자체가 목표가 되고, 이후 운영 및 관리가 소홀해짐
문제점
- 오탐/과탐, 설정 미비 등으로 인해 실제 필요한 보호가 되지 않을 수 있음
- 인간 실수, 내부자 위협은 기술 솔루션만으로 완벽하게 막기 어려움
- 프로세스, 운영체계(OS) 레벨, 네트워크 계층 등 다계층 방어가 되어야 함
개선 방안
- 다계층 보안(Multi-layered Security)
- 네트워크(방화벽, IDS/IPS), 엔드포인트(백신, EDR), 애플리케이션(WAF) 등 계층별 통합 보안 체계
- 정기 모니터링/로그 분석
- SIEM(Splunk, Elastic Stack, ArcSight 등) 도입으로 실시간 이상 징후 탐지
- 보안 인식 교육
- 피싱 메일 훈련, 소셜 엔지니어링 예방 교육 등을 통해 내부자의 실수 최소화
점검 포인트
- 보안 솔루션의 정책이나 규칙이 최신 위협에 맞춰 주기적으로 업데이트되고 있는가?
- 보안 솔루션 운영 담당자(관리자)는 오탐이나 과탐을 적절히 조정하고 있는가?
- 사용자 보안 인식 교육이 얼마나 자주, 어떤 방식으로 이루어지고 있는가?
4. "내부 네트워크는 안전하다."
- 방화벽 내부의 사설망 또는 내부 네트워크는 외부 공격으로부터 보호되어 있다고 가정
- VPN 같은 보안 채널만 적용하면 외부 침입이 없을 것이라 믿음
문제점
- 내부자 위협(Insider Threat): 내부 사용자가 의도적, 또는 무의식적으로 보안 사고를 일으킬 수 있음
- 피싱 및 잘못된 설정 등으로 내부 네트워크도 쉽게 위협받을 수 있음
- VPN이 적용되어 있어도 약한 인증이면 쉽게 뚫릴 수 있음
개선 방안
- 제로 트러스트(Zero Trust) 모델 적용
- 네트워크 영역에 상관없이 모든 접근 요청에 대해 ‘끊임없이 인증, 권한 검증’
- 최소 권한 원칙(Principle of Least Privilege) 준수
- 사용자와 시스템이 실제 필요한 권한만 갖도록 제한
- 네트워크 분할(Segmentation) 및 내부 모니터링
- VLAN, 서브넷 등을 통해 내부망을 세분화하여 침입 확산을 방지
점검 포인트
- 내부망에서도 단말 간 직접 통신(예: SMB 공유, RDP)이 과도하게 허용되어 있지 않은가?
- VPN 접근 시 다중 인증(MFA)이나 강화된 ID/PW 정책을 적용했는가?
- 내부망 구간에 대한 로깅 및 패킷 분석 도구(NAC, 내부 IDS 등)가 운영되고 있는가?
5. "패치를 나중에 해도 된다."
- 서비스 중단이 우려되어 패치를 미루거나, 업데이트 후 문제 발생을 겁내어 방치
- 특히 업무 시간대에 패치 적용이 어려운 경우, 무기한 연기되기도 함
문제점
- 알려진 취약점(Common Vulnerabilities and Exposures, CVE)이 공개된 상태에서 빠른 공격이 발생
- 대규모 랜섬웨어(WannaCry, NotPetya 등) 공격은 취약점이 패치되지 않은 시스템을 집중 타깃
- 장기간 미패치 시스템으로 인해 전체 인프라가 위협에 노출
개선 방안
- 패치 관리 프로세스 수립
- 테스트 환경에서 선 적용 후, 신속히 운영 환경에 배포
- 예시: WSUS(Windows Server Update Services), Linux 패키지 관리자(apt, yum 등) 자동화
- 장애 대비 계획 수립
- 패치 적용 전 백업 및 롤백 시나리오 마련
- 자동화된 패치 관리 도구 활용
- Ansible, Chef, Puppet 등으로 서버 패치 자동화
점검 포인트
- 최신 보안 공지(KISA, NIST, MS 등)를 주기적으로 확인하고 있는가?
- 패치 테스트 환경은 구축되어 있으며, 적용 후 검증 프로세스가 체계화되어 있는가?
- 고가용성(HA) 환경이나 롤백 계획을 통해 서비스 중단 시간을 최소화하고 있는가?
6. "암호화는 필요 없다."
- 내부망 또는 특정 서비스 내 데이터이므로 암호화가 불필요하다고 판단
- 암호화 구현이 복잡하고 성능 저하 문제를 우려
문제점
- 미암호화 데이터 전송 시 도청, 탈취 위험 (Wi-Fi 스니핑, MITM 공격 등)
- 저장 데이터도 평문이면 침해 시 정보가 쉽게 유출
- 각종 개인정보보호법, 컴플라이언스 위반 가능
개선 방안
- 전송 중 암호화 (TLS/HTTPS)
- 예시: 웹 서비스에서 Let’s Encrypt를 통한 무료 TLS 인증서 적용
- SSH/SFTP로 파일 전송
- 저장 데이터 암호화
- 데이터베이스 컬럼 암호화(예: AES-256)
- 파일/디스크 레벨 암호화(LUKS, BitLocker 등)
- 민감 정보 접근 통제 병행
- 암호화만으로 부족하므로 권한 관리, 로깅, 모니터링도 수행
점검 포인트
- 데이터베이스나 파일서버에서 민감 정보를 평문으로 저장·전송하고 있지 않은가?
- TLS 인증서나 암호화 키 관리 정책은 마련되어 있는가?
- 민감 정보가 담긴 테이블, 폴더 등에 대한 접근 권한이 최소화되어 있는가?
7. "로그는 나중에 보자."
- 로그 분석은 시간이 많이 들고, 우선순위가 낮다고 판단
- 단순 저장만 하고, 실제로 모니터링이나 분석을 하지 않는 경우
문제점
- 보안 사고 발생 시 원인 추적이 불가능하거나 오래 걸림
- 이상 징후를 사전에 감지할 기회를 놓침
- 컴플라이언스(내부 감사, 감독기관 요구) 대응 어려움
개선 방안
- 중앙 집중식 로그 관리(SIEM) 도입
- Splunk, Elastic Stack(ELK), ArcSight 등 활용
- 로그 보관 정책 수립
- 최소 6개월~1년 이상 보관
- 중요한 시스템은 더 길게(예: 금융권은 5년 보관 등)
- 실시간 알림/대시보드 구성
- 의심스러운 이벤트(특정 계정의 이상 로그인, 대량 실패, 네트워크 공격 시도 등)에 대한 알림
점검 포인트
- 모든 주요 시스템(서버, 네트워크 장비, 애플리케이션)의 로그가 중앙 로그 서버에 정상 전송되는가?
- 로그 검색, 분석 작업에 필요한 인력 및 도구가 준비되어 있는가?
- 규제나 감사 요구사항에 맞춰 로그 보관 기간과 형식을 준수하고 있는가?
8. "모두가 관리자 계정이 필요하다."
- 편리함을 위해 모든 사용자에게 관리자 권한(Administrator, root 등)을 부여
- 소프트웨어 설치나 환경 설정 변경에 제한이 없도록 운영
문제점
- 피싱·악성코드에 감염될 경우, 전체 시스템이 위험에 노출
- 권한 관리가 허술해져, 기밀 데이터에 비인가 접근이 가능해짐
개선 방안
- 권한 분리(Separation of Duties) 원칙 준수
- 역할 기반 접근 제어(RBAC) 도입, LDAP/AD 그룹 정책 활용
- 관리자 계정 최소화 & MFA 적용
- 필수 담당자 외에는 관리자 권한 금지, 다중 인증(OTP, 스마트카드 등)으로 접속 강화
- 정기 권한 검토
- 조직 변경, 인사 이동 시 자동으로 권한 재조정
점검 포인트
- 현재 관리자 권한을 가진 계정의 수는 적정한가?
- 관리자 계정으로만 접근 가능한 서비스/시스템이 너무 많지 않은가?
- MFA 등 추가 보안 절차가 관리자 로그인을 보호하고 있는가?
9. "오픈 소스는 무료니까 그냥 쓰자."
- 비용 절감을 위해 오픈 소스 라이브러리나 솔루션을 충분히 검토 없이 도입
- 라이선스나 보안 업데이트, 유지보수 계획을 고려하지 않음
문제점
- 취약점 패치 지연: 오픈 소스 커뮤니티가 활발하지 않으면 보안 결함이 방치될 수 있음
- 공급망 공격(Supply Chain Attack): 악성 코드가 포함된 오픈 소스 배포본, 라이브러리
- 라이선스 분쟁: GPL, MIT, Apache 등 라이선스 조항 미준수 시 법적 문제 발생
개선 방안
- SBOM(Software Bill of Materials) 작성
- 사용하는 모든 오픈 소스 라이브러리 목록, 버전, 라이선스 명시
- 보안 상태 및 유지보수 활동 점검
- GitHub 스타나 이슈, 커뮤니티 활동 등을 통해 프로젝트 활성도 확인
- 보안 스캔 도구 활용
- Snyk, Dependabot(GitHub), OWASP Dependency-Check 등으로 자동 취약점 점검
점검 포인트
- 내부에서 사용하는 오픈 소스 목록을 체계적으로 관리하고 있는가?
- 라이선스 호환성(GPL, LGPL, Apache, MIT 등)을 준수하고 있는가?
- 최신 버전이나 보안 패치가 필요한 라이브러리가 방치되고 있지 않은가?
10. "백업은 신경 쓸 필요 없다."
- 백업 중요성을 과소평가하거나, 백업은 하고 있으나 복구 테스트를 해보지 않음
- 랜섬웨어 같은 치명적 사건을 경험하고 나서야 비로소 대비
문제점
- 랜섬웨어 공격 시 복구 불가능
- 하드웨어 장애, 자연재해 등으로 데이터 영구 손실
- 백업이 있었더라도 복구 테스트를 안 했다면 실제 복원 불가 가능성
개선 방안
- 3-2-1 백업 규칙
- 중요한 데이터는 3개의 복사본을 2종류의 다른 저장 매체에 보관, 이 중 1개는 오프사이트(Off-site)
- 백업 복구 테스트 정기 수행
- DR(Disaster Recovery) 훈련, 실제 데이터를 이용한 복구 시뮬레이션
- 백업 데이터 보안
- 백업본 암호화, 접근 권한 제한, 오프라인 보관
점검 포인트
- 백업이 자동화되어 있는가? (예: 스케줄링, 장애 시 재시도)
- 백업 복구 시뮬레이션 테스트 결과는 어떠하며, 개선점은 무엇인가?
- 백업 서버 또는 매체 자체가 랜섬웨어나 내부자 공격에 안전한가?
종합 권고
- 위험 인식(Risk Awareness)
- 조직의 규모를 막론하고 누구든 보안 사고의 잠재적 표적이 될 수 있음을 전사적으로 인식해야 합니다.
- 최신 위협 동향을 주기적으로 모니터링하고, 필요한 보안 업데이트를 빠르게 적용하세요.
- 정책 수립(Security Policies)
- 최소 권한 원칙, 권한 분리, 암호화 정책, 로그 관리 등 기본이 되는 보안 정책과 표준 운영 절차(SOP)를 마련하세요.
- 각종 컴플라이언스(개인정보 보호법, ISO 27001, NIST CSF 등)와 연계하여 체계화하면 더욱 효과적입니다.
- 도구 활용(Security Tools)
- 보안 솔루션은 필수적이지만, 단일 솔루션에만 의존해서는 안 됩니다.
- SIEM, EDR, WAF, IDS/IPS 등 다계층 솔루션을 통합적으로 운영하고, 정기적으로 설정과 정책을 점검하세요.
- 교육(Education & Awareness)
- 내부 구성원의 보안 인식이 가장 중요합니다.
- 피싱·악성 메일 훈련, 소셜 엔지니어링 방지 교육 등으로 내부자 실수를 최소화하고, 보안을 ‘우리 모두의 문제’로 인식시키세요.
- 지속적 개선(Continuous Improvement)
- 보안은 한 번에 완성되는 프로젝트가 아니라, 지속적으로 개선·운영해야 하는 프로세스입니다.
- 보안 사고나 취약점 발견 시 RCA(Root Cause Analysis)를 통해 재발 방지책을 마련하고, 문서화·교육까지 연결하세요.
활용사례
- 랜섬웨어 공격 대비
- 정기 패치, 3-2-1 백업 전략, SIEM 알림 시스템을 마련해 사전·사후 방어 가능
- 내부에서 반복적으로 랜섬웨어 훈련 시나리오를 돌려서 구성원 인식 제고
- 오픈소스 공급망 보안
- SBOM 체계를 마련하고 Dependabot 같은 툴을 적용해 취약점이 있는 라이브러리를 자동으로 업데이트
- 개발팀과 보안팀이 협업하여 코드 리뷰 및 빌드 파이프라인에서 보안 검사(Static Analysis, Software Composition Analysis) 수행
- 제로 트러스트 도입
- 내부망을 신뢰하지 않고, 모든 사용자·디바이스에 대해 다중 인증 및 세분화된 권한 검증을 시행
- VPN 접속 시에도 IP·기기·시간대·접속 지역 기반으로 액세스 정책 강화
잘못된 통념을 방치하면 조직 전반의 보안 수준이 낮아지고, 결국 심각한 보안 사고로 이어질 수 있습니다. 이를 예방하기 위해서는 위험 인식, 정책 수립, 도구 활용, 교육이라는 네 가지 축을 체계적으로 운영해야 합니다. 또한 보안은 단일 솔루션으로 완성되지 않으며, 지속적인 점검과 개선이 필수적이라는 점을 항상 염두에 두어야 합니다.
- 핵심 메시지: 보안은 “지속적인 과정”이며, 전사적 관심과 참여 없이는 결코 완성될 수 없습니다.
- 실행 방안: 위에 제시된 10가지 나쁜 상식을 다시 점검하고, 각 항목별 점검 포인트를 반영해 내부 정책과 절차를 개선하세요.
위 내용을 바탕으로 조직 내 보안 전략을 재정비하고, 전사 구성원들에게 체계적인 보안 안내 및 점검을 수행하기 바랍니다. 필요하다면 외부 전문가 컨설팅이나 보안 솔루션 파트너를 통해 최신 보안 위협에 효율적으로 대응할 수 있는 지침을 마련하는 것도 권장합니다.
728x90
댓글