설계보안항목 정의 및 설계시 고려사항
2. 보안기능 설계항목
1) 인증 대상 및 방식
취약점 개요
중요 기능이나 리소스 요청 시 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하여 중요 정보나 리소스가 노출 (적절한 인증 없는 중요기능 허용)
설계 시 고려사항
1) 중요기능이나 리소스에 대해서 인증 후 사용 정책 적용
- 시스템 설계 시 중요 기능을 분류하고, 식별된 중요기능에 대해 일괄적으로 인증을 요구하는 시스템이 구성되도록 설계
- 직접적으로 기능과 인증을 매핑시켜 처리하는 컴포넌트를 개발하거나, 인증 기능을 제공하는 프레임워크 또는 라이브러리를 활용하여 중앙집중식 인증 적용
2) 안전한 인증방식 사용으로 인증우회나 권한 상승 방지
- 인증 정보는 서버 측에 저장하여 인증이 필요한 기능이나 리소스에 접근을 시도할 때 서버에서 인증 여부를 확인
- 중요 기능에 대해 2단계(2 factor)인증 고려
- 인증 기능을 제공하는 프레임워크 또는 라이브러리
- JAVA: Spring Security
- ASP.NET: .NET Framework
- PHP: Zend Framework, Symfony
2) 인증 수행 제한
취약점 개요
로그인 시도에 대한 횟수를 체크하지 않으면 패스워드 무작위 대입공격 시도 가능
설계 시 고려사항
1) 로그인 기능 구현 시 인증횟수를 제한하고 초과된 인증 시도에 대해 인증제한 정책 적용
- 로그인 시도 횟수 3~5번 이내로 제한하고 초과하여 실패하는 경우 추가 입력값을 요구하거나 계정잠금 수행
매커니즘 설계
- 사용자 ID별, 세션 ID별 로그인 횟수 추적을 위해 사용자 DB 테이블에
로그인 실패 횟수/계정잠금여부/마지막으로 성공ㆍ실패한 로그인 시간 정보/로그아웃한 시간정보들을 저장할 수 있도록 설계 - 일정 횟수 이상 연속적으로 로그인 실패 시 사용자 ID와 패스워드 외 추가적인 확인정보를 저장
- 사용자 ID별, 세션 ID별 로그인 횟수 추적을 위해 사용자 DB 테이블에
- 계정정보 입력 시 자동입력 방지 문자와 같은 장치 마련
- 활용 가능한 서비스 및 솔루션 (CAPTCHA 기능 제공)
- 서비스: reCAPTCHA
- 솔루션: BotDetect CAPTCHA Generator
2) 실패한 인증 시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있도록 설계
- 반복된 로그인 실패에 대한 로깅 정책을 설정하고 로그 기록을 통해 허용되지 않은 로그인 시도 분석
3) 비밀번호 관리
취약점 개요
- 취약한 비밀번호 사용
회원가입 시 안전한 패스워드 규칙이 적용되지 않아 취약한 패스워드로 회원가입이 가능할 경우 무차별 대입공격을 통해 패스워드 누출 가능- 취약한 비밀번호 복구
패스워드 복구 매커니즘(아이디/패스워드 찾기 등)이 취약한 경우 공격자가 불법적으로 다른 사용자의 패스워드를 획득, 변경, 복구 가능
- 하드코드된 비밀번호
- 프로그램 코드 내부에 하드코드된 패스워드를 포함하고 이를 이용하여 내부 인증에 사용하거나 외부 컴포넌트와 통신하는 경우, 관리자 정보 노출의 위험성이 있음.
- 하드코드된 패스워드가 인증실패를 야기할 경우 실패의 원인 파악이 어려움
설계 시 고려사항
1) 패스워드 설정 시 한국인터넷진흥원『암호이용안내서』의 패스워드 설정 규칙 적용
- 패스워드 안전성 검증 솔루션
- PHP, JSP, ASP: 패스워드 안전성 검증 S/W
2) 네트워크를 통해 패스워드 전송 시 반드시 패스워드를 암호화하거나 암호화된 통신 채널을 이용
- 공중망 환경에서 패스워드와 같은 중요 정보 송ㆍ수신 시 보호대책 필요
- TLS, VPN등과 같은 다양한 통신 암호기술 적용 가능
3) 패스워드 저장 시 솔트가 적용된 안전한 해쉬함수를 사용 (해쉬함수는 서버에서 실행)
- 패스워드는 복호화되지 않는 일방향 해쉬 함수를 사용해 암호화
일방향 해쉬 함수의 문제점을 해결하기 위해 솔트값을 추가 (소프트웨어 개발보안 가이드, 105page 참고)
4) 패스워드 재설정/ 변경 시 안전하게 변경할 수 있는 규칙을 정의하여 사용
4) 중요자원 접근 통제
취약점 개요
- 관리자 페이지 노출
관리자 페이지가 인터넷을 통해 접근 가능할 경우, 공격자의 주 타겟이 되어 공격자의 SQL삽입, 무차별 대입공격 등 다양한 형태의 공격의 빌미를 제공하게 됨- SSI 삽입
SSI(Server-side Includes)는 HTML 문서 내 변수 값으로 입력된 후, 이를 서버가 처리하게 되는데, 이 때 인젝션 명령문이 수행되어 서버 데이터 정보가 누출됨
- 부적절한 인가
프로그램이 모든 가능한 실행경로에 대해 접근제어를 검사하지 않거나 불완전하게 검사하는 경우, 공격자는 접근 가능한 실행 경로를 통해 정보를 유출할 수 있음
(*ACL(Access Control List): 접근제어목록)
- 중요 자원에 대한 잘못된 권한 설정
SW가 중요한 보안관련 자원에 대하여 읽기 또는 수정하기 권한을 의도하지 않게 허가할 경우 권한을 갖지 않은 사용자가 해당 자원을 사용하게 될 수 있는 취약점
설계 시 고려사항
- RBAC(역할 기반 접근제어) 모델을 사용하여 기업, 정부 등 다수의 사용자와 정보객체들로 구성된 조직체계에서 사용자에게 할당된 역할을 기반으로 권한을 부여하도록 설계
<RBAC 데이터 모델>
- 접근제어목록 (Access Control List) 구성하여 자원에 대한 접근 권한 설정
- ex) Spring Security 프레임 워크 사용 시 ACL 모듈 추가 가능. ACL 관련 기능을 애플리케이션에 적용하여 객체에 대한 접근 제어 구현 가능
1) 중요 자원에 대한 접근통제 정책 수립 및 적용
- 접근 통제 정책 수립 시 최소 권한(1)의 원칙과 권한 분리(2)정책에 따라 자원에 대한 권한을 할당
- 자원에 대한 접근은 요구조건을 충족할 때만 허가하도록 설계
2) 중요 기능에 대한 접근통제 정책 수립 및 적용
- 중요 기능에 대한 접근권한은 최소권한으로 설정
- 중요 기능에 대한 접근통제 정책을 설정하고, 사용자별 또는 그룹별 접근 체크
- 프로그램에서 사용자 또는 자원에 대한 권한의 할당, 수정, 확인, 검사를 수행하여 의도치 않은 범위의 권한을 획득하지 않도록 함
- 파라미터가 변조되지 않았는지 확인하는 절차 구현
- 상위 권한을 사용해 수행되는 기능을 구현해야 하는 경우, 권한상승은 가능한 가장 마지막에 수행하고 수행종료 즉시 원상 복귀
3) 관리자 페이지에 대한 접근 통제 정책 수립 및 적용
- 관리자 페이지 URL은 쉽게 추측할 수 없도록 설정
- 관리자 페이지의 원격 연결 시 암호화 통신 채널 사용
- 관리자 페이지가 외부망에 있는 경우 IP통제, 80번이 아닌 별도의 포트 사용, SSL 적용, 추가 인증 요구
- 관리자 페이지가 내부망에 있는 경우 80번이 아닌 별도의 포트 사용, SSL 적용 권고
- 활용가능한 프레임워크 또는 라이브러리
- Java: Spring Security
- ASP.NET: .NET Framework
- PHP: PHP-RBAC
5) 암호키 관리
취약점 개요
- 하드코드된 암호키
코드 내부에 하드코드된 암호화 키를 사용하여 암호화를 수행하면 암호화된 정보가 유출될 가능성이 높아짐- 주석문 안에 포함된 암호키
주석문 안에 암호키에 대한 설명이 포함되어 있는 경우, 공격자가 소스코드에 접근할 수 있다면 아주 쉽게 암호키가 노출됨
설계 시 고려사항
1) DB데이터 암호화에 사용되는 암호키는 한국인터넷진흥원『암호이용안내서』 에서 정의하고 있는 방법을 적용
-
암호키 관리 규칙 생성 시 고려사항 (소프트웨어 개발보안 가이드, 118page 참고)
-
조직의 보호 목적에 따라 암호키 관리 수준 지정
NIST에서 제정한 FIPS 140-2의 레벨로, 조직의 보호목적에 따라 적절히 채택
-
키 생명주기 기준 암호화 키 관리 프로세스 구축
- 키 생성 - 암호화키와 패스워드를 생성, 사용, 관리하는 사람 등을 명시하고 키를 생성하는 데 사용하는 프로그램 등 어떠한 방법으로 생성하는지에 대한 절차를 명시
- 키 사용 - 암호화키와 패스워드를 어떠한 방법으로 사용하는지에 대한 절차, 생성한 키의 종류에 따른 변경주기, 인가된 사용자만 키에 접근할 수 있는 접근통제 방법 및 요구사항 등을 명시
- 키 폐기 - 키의 사용주기가 다 된 경우 및 사용 용도가 끝난 경우 등 생성한 키를 폐기하여야 하는 경우를 명시하고, 암호화키와 패스워드를 안전하게 폐기하는 절차 및 요구사항 등을 명시
-
키 복구 방안
사용자 퇴사 등으로 인해 사용자 이외의 사람에게 키 복구가 필요한 경우, 암호화키는 정보보호 담당자의 관리 하에 암호화키 관리대장 등에서 복구하고, 패스워드는 정보보호담당자가 임시 패스워드를 발급하는 등 키 복구에 대한 방안 마련 -
암호키 사용 유효기간
암ㆍ복호화 키의 사용이 일정시간을 넘은 경우, 사용자 인터페이스를 통해 키 사용기간이 경과했음을 알리고 새로운 키 생성을 권장하도록 설계
<암호키 사용 유효기간 (NIST 권고안)>
2) 설정 파일(xml, Properties) 내의 중요정보 암호화에 사용되는 암호키는 암호화하여 별도의 디렉터리에 보관
6) 암호 연산
취약점 개요
- 취약한 암호 할고리즘 사용
지나치게 간단한 인코딩 함수를 사용하면 패스워드를 안전하게 보호할 수 없음
- 충분하지 않은 키 길이 사용
검증된 암호화 알고리즘을 사용하더라도 키 길이가 충분히 길지 않으면 짧은 시간 안에 키를 찾아낼 수 있고, 이를 이용해 공격자가 암호화된 데이터나 패스워드를 복호화 할 수 있음
- 적절하지 않은 난수 사용
예측가능한 난수를 사용하는 것은 시스템의 보안약점을 유발
(*사용 지양: java.Math.random()
*사용 권고: java.util.Random or java.security.SecureRandom)
- 솔트 없이 사용하는 일방향 해쉬 함수
패스워드를 솔트(Salt)없이 해쉬하여 저장하면 레인보우 테이블을 활용한 공격이 가능
설계 시 고려사항
1) 대칭키 또는 비대칭키를 이용해서 암/복호화를 수행하는 경우 한국인터넷진흥원『암호이용안내서』에 서 정의하고 있는 암호화 알고리즘과 안전성이 보장되는 암호키 길이를 사용해야 함 (소프트웨어 개발보안 가이드, 126page 참고)
안정성이 보장되는 암호키 길이와 암호알고리즘을 확인 후 사용
2) 복호화되지 않는 암호화를 수행하기 위해 해쉬함수를 사용하는 경우 안전한 해쉬 알고리즘과 솔트값을 적용하여 암호화해야 함
해쉬함수는 사용 목적과 보안 강도에 따라 선택하여 이용
3) 난수 생성 시 안전한 난수 생성 알고리즘을 사용
7) 중요 정보 저장
취약점 개요
- 중요정보 평문저장
메모리나 디스크에서 처리하는 중요데이터(개인정보, 인증정보, 금융정보)가 제대로 보호되지 않을 경우, 보안이나 데이터의 무결성을 잃을 수 있음- 사용자 하드디스크에 저장된 쿠키를 통한 정보 노출
개인정보, 인증정보 등이 영속적인 쿠키(Persistent Cookie)에 저장된다면 공격자는 쿠키에 접근할 수 있는 보다 많은 기회를 가지게 되고 시스템을 취약하게 만듬
설계 시 고려사항
1) 중요정보 또는 개인정보는 암호화하여 저장
- 중요정보가 다뤄지는 '안전영역'을 설정하고 중요정보가 해당 영역 외부로 누출되지 않도록 설계
- 서버의 DB나 파일 등에 저장되는 중요정보는 반드시 암호화하여 저장하고 '7)암호연산'의 암호화 정책이 적용되어야 함
- 특히 쿠키, HTML5 로컬 저장소와 같은 클라이언트 측 하드 드라이브에는 중요정보가 저장되지 않도록 설계해야하며 부득이한 경우에는 반드시 민감정보를 암호화
- HTML 코드는 사용자에게 공개되어 있는 것이나 마찬가지이므로 중요한 로직 및 주석처리는 서버측 언어에서만 처리되도록 설계
2) 중요정보가 메모리에 남지 않도록 설계
- 개인정보 또는 특정 금융정보 처리 기능 구현 시 더이상 필요하지 않은 데이터에 대해 메모리를 0으로 초기화하여 중요 데이터가 메모리에 남지 않도록 시큐어 코딩 규칙 정의
- 특히 민감정보를 포함하는 페이지는 사용자 측 캐싱을 비활성화하도록 제한적인 캐시 정책 수립. 부득이한 경우 캐싱되는 정보는 반드시 암호화하여 저장하도록 설계
- 인증정보와 같은 민감한 정보를 포함하는 웹 폼 구현 시 자동완성 기능 비활성화
8) 중요 정보 전송
취약점 개요
프로그램이 보안과 관련된 민감한 데이터를 평문으로 송ㆍ수신할 경우, 통신채널 스니핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있음 (중요정보 평문 전송)
설계 시 고려사항
1) 인증정보와 같은 민감정보 전송 시 암호화하여 전송
2) 쿠키에 포함되는 정보는 반드시 암호화하여 전송
쿠키에는 중요정보가 포함되지 않도록 설계하는 것이 우선이지만 부득이한 경우 반드시 세션 쿠키로 설정되어야 하며, 전달 정보는 반드시 암호화
[출처] 행정자치부 SW 개발보안 가이드 https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000015&nttId=57473
