OWASP & 안전한 시스템 설계 8원칙

이윤범·2023년 11월 2일
0

정보보호

목록 보기
5/11

시스템 유지보수도 중요하지만 안전한 설계를 통한 사전예방이 더 중요하다. OWASP에서 제시하는 취약점들을 참고하면 실제 설계 간 도움이 될 것이다. OWASP와 안전한 시스템 8원칙에 대해 살펴보자.

  • OWASP(Open Web Application Security Project) : OWASP는 소프트웨어 보안 향상을 목표로 하는 비영리 조직이다. OWASP는 애플리케이션을 취약점으로부터 보호하기 위한 보안 모범 사례를 기업에 안내하기 위해 상위 10개 항목을 개발했다. 이 오픈 커뮤니티 프로젝트는 위협적인 환경이 계속 진화함에 따라 항목을 정기적으로 업데이트하고 있다.

CF> OWASP TOP 10 : 2021

  • A1: Broken Access Control[접근 권한 취약점]

    엑세스 제어는 사용자가 권한을 벗어나 행동할 수 없도록 정책을 시행한다. 만약 엑세스 제어가 취약하면 사용자는 주어진 권한을 벗어나 모든 데이터를 무단으로 열람, 수정 혹은 삭제 등의 행위로 이어질 수 있다.

  • A2 : Cryptographic Failures[암호화 오류]

    Sensitive Data Explosure(민감한 데이터 노출)의 명칭이 2021년 Cryptographic Failures(암호화 오류)로 변경되었다. 적절한 암호화가 이루어지지 않으면 데이터가 노출될 수 있다.

  • A3 : Injection[인젝션]

    인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 취약점이 발생한다.

  • A4 : Insecure Design[안전하지 않은 설계]

    누락되거나 비효율적인 제어 설계로 표현되는 다양한 취약점

  • A5 : Security Misconfiguration[보안설정오류]

    불필요한 기능이 활성화 되거나 설치되었을 때, 기본계정 및 암호화가 변경되지 않았을 때, 지나치게 상세한 오류 메시지를 노출할 때, 최신 보안 기능이 비활성화 되거나 안전하지 않게 구성되었을 때 발생한다.

  • A6 : Vulnerable and Outdated Components[취약하고 오래된 구성요소]

    취약하고 오래된 요소는 지원이 종료되었거나 오래된 버전을 사용할 때 발생한다.

  • A7 : Identification and Authentication Failures[식별 및 인증 오류]

    Broken Authentication(취약한 인증)으로 알려졌던 해당 취약점은 Identification Failures(식별실패)까지 포함하여 더 넓은 범위를 포함할 수 있도록 변경되었다.

  • A8 : Software and Data Integrity Failures[소프트웨어 및 데이터 무결성 오류]

    2021년 새로 등장한 카테고리로 무결성을 확인하지 않고 소프트웨어 업데이트, 중요 데이터 및 CI/CD 파이프라인과 관련된 가정을 하는데 중점을 둔다.

  • A9 : Security Logging and Monitoring Failures[보안 로깅 및 모니터링 실패]

    Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링) 명칭이었던 카테고리가 Security Logging and Monitoring Failures(보안 로깅 및 모니터링 실패)로 변경되었습니다. 로깅 및 모니터링 없이는 공격활동을 인지할 수 없다. 이 카테고리는 진행중인 공격을 감지 및 대응하는데 도움이 된다.

  • A10 : Server - Side Request Forgery[서버 측 요청 위조]

    2021년 새롭게 등장했다. SSRF 결함은 웹 애플리케이션이 사용자가 제공한 URL의 유효성을 검사하지 않고 원격 리소스를 가져올 때마다 발생한다. 이를 통해 공격자는 방화벽, VPN 또는 다른 유형의 네트워크 ACL(엑세스 제어 목록)에 의해 보호되는 경우에도 응용 프로그램이 조작된 요청을 예기치 않은 대상으로 보내도록 강제할 수 있다.

■ 안전한 시스템 설계 8원칙

1. 최소한의 권한(Least Privilege)

정의 : 각 사용자 프로그램은 가능한 최소한의 권한을 사용하여 작동해야 한다.

  • 시스템 내 계정별, 필요한 권한만 부여
    ex) 리눅스 / 유닉스 setuid(또는 setgid)
  • 일반 사용자에게 관리자 권한을 부여하면 공격자가 해당 계정 탈취시 피해 확산

2. 매커니즘의 효율적 사용(Economy of mechanism / Simplicity)

정의 : 보호 시스템 설계는 가능한 단순하고 작아야한다(=경제적이어야 한다)

  • 시스템 동작간 예기치 못한 오류 통제 철저, 의도한 기능만 구현

3. 오픈 설계(Open Design)

정의 : 보호 시스템(메커니즘)은 공격자의 무지에 의존하지 않아야 한다
ex) 공개키 방식, 암호화 알고리즘

4. 완벽한 조정(Complete Mediation)

정의 : 시스템으로의 모든 접근은 시스템(관리자)으로부터 검증받을 수 있어야 한다

  • 모든 객체(사용자)의 시스템내 모든 자원 접근에 대한 감사/관리
    ex) 로그 작성, 방화벽, 사용자 인증 시스템

5. 고장 안전 디폴트(Fail - Safe defaults)

정의 : 시스템 실행이 실패(오류 발생)하더라도, 가장 안전한 결과가 나올 수 있도록 설계되어야 한다.

  • 오동작 탐지시, 프로그램 즉각적으로 서비스 거절 / 요청 처리 중지[시스템 전체 중지(X)]
  • 가장 안전한 결과 : 시스템 초기 상태(디폴트) 등

6. 권한 분리(Separation of privilege)

정의 : 객체에 대한 접근은 한가지 이상의 조건에 의존하도록 설계되어야 한다.

  • 하나의 인증 수단을 통과하더라도 시스템 전체 모든 권한을 획득하지 못하도록 설정

7. 최소한의 공통 메커니즘(Least common mechanism)

정의 : 공유 메커니즘(또는 자원)의 수와 그 사용을 최소화한다

  • 다수의 공유 자원 사용시, 예상치 못한 정보 흐름/유출 발생 가능
    ex) 레이스 컨디션 공격(Race Condition Attack)

8. 심리학적 수용성(Psychological acceptability)

정의 : 사용자가 시스템을 사용하기 쉽도록 설계하여, 보안 메커니즘을 목적에 맞게 사용하도록 유도한다
CF) 보안의 3요소 중 '가용성(Availability)'
ex) 비밀번호를 특수문자 포함 100글자 이상 설정하도록 지시한다면?

profile
🇰🇷

0개의 댓글