중요 자원 접근통제
중요자원(프로그램 설정, 민감한 사용자 데이터 등)을 정의하고 정의된 중요자원에 대한 접근을
통제하는 신뢰할 수 있는 방법(권한 관리 포함) 및 접근 통제 실패 시 대응방안을 설계해야 한다.
보안대책
- 중요자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
- 중요기능에 대한 접근통제 정책을 수립하여 정굥해야 한다.
- 관리자 페이지에 대한 접근통제 정책을 수립하여 적용해야 한다.
취약점 개요
- 관리자 페이지 노출
관리자 페이지가 인터넷으로 접근 가능할 경우 해당 페이지는 공격자의 주 공격대상으로 SQL삽입,
무차별대입 공격 등 다양한 형태의 공격의 빌미를 제공하게 되는 취약점이다.
- SSI 삽입
SSI(Server-side Includes)는 HTML 문서 내 변수 값으로 입력된 후 이를 서버가 처리하게 되는데
이 때 인젝션 명령문이 수행되어 서버 데이터 정보가 누출되는 취약점이다.
Exec cmd=”ls –la” 를 특정 데이터에 입력 하여 서버로 전송
- 부적절한 인가
프로그램이 모든 가능한 실행경로에 대해서 접근제어를 검사하지 않거나 불완전하게 검사하는경우
공격자는 접근 가능한 실행경로로 정보를 유출할 수 있는 취약점
- 중요자원에 대한 잘못된 권한 설정
소프트웨어가 중요한 보안 관련자원에 대하여 읽기, 수정 등의 권한을 의도하지 않게 허가할 경우 권한을
갖지 않은 사용자가 해당 자원을 사용하게 될 수 있는 취약점이다.
설계 시 고려사항
RBAC(역할기반 접근제어) 모델을 사용하여 기업, 정보 등 다수의 사용자와 정보객체들로 구성된 조직체계에서 사용자에게
할당된 역할을 기반으로 권한을 부여하도록 설계한다.
접근제어목록(Access Control List)을 구성하여 자원에 대한 접근 권한을 설정한다.
예를 들면 Spring Security 프레임워크 사용 시 ACL 모듈을 추가할 수 있다
a. 모든 도메인 객체에 대한 ACL엔트리를 효과적으로 검색하고 수정한다.
b. 메소드 호출에 앞서 각 사용자가 객체에 대해 특절 작업을 수행할 권한이 있는지 검증한다
c. 메소드 호추이 끝난 후 각 사용자가 객체(또는 반환되는 객체)에 대해 특정 작업을 수행할 권한이 있는지 검증한다.
./ 중요 자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
중요자원에 대한 접근권한을 최소권한으로 설정한다.
중요자원에 대한 접근 통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
중요자원(파일,프로세스,메모리,데이터베이스 등)에 대한 접근을 통제하기 위해 ACL이나 RBAC을 적용하도록 설계
접근통제 정책을 수립할 때는 최소권한의 원칙과 권한 분리 정책에 따라 자원에 대한 권한을 할당하고 자원에 대한
접근은 요구 조건을 충족할 때만 허가하도록 설계해야 한다.
./ 중요기능에 대한 접근통제 정책을 수립하여 적용해야 한다.
주요기능에 대한 접근 통제는 소프트웨어를 익명 일반 특권사용자와 관리자 영역으로 구분하여 역할 기반 접근통제(RBAC) 정책
및 비즈니스 로직에 따라 접근통제가 실시 되도록 다음과 같은 조건에 따라 설계한다.
. 중요기능에 대한 접근권한은 최소권한으로 설정한다.
. 중요기능에 대한 접근통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
. 프로그램에서 사용자 또는 자원에 대한 권한의 할당, 수정, 확인, 검사를 수행하여 의도치 않은 범위의 권한을 획득하지 않도록 한다.
. 파라미터 변조로 인증이 올바르게 수행되지 않을 수 있으므로 파라미터가 변조되지 않았는지 확인하는 절차를 구현한다.
. 상위권한을 사용해 수행되는 기능을 구현해야 하는 경우 권한상승은 가능한 가장 마지막에 수행하고 수행 종료 즉시 원상 복귀한다.
./ 관라자 페이지에 대한 접근 통제 정책을 수립하여 적용해야 한다.
. 관리자 페이지의 URL은 쉽게 추측할 수 없도록 설정한다.
. 관라지 페이지 접속 시 암호화 통신 채널(TLS 등)을 사용해야 한다.
. 관리자 페이지에 접속 가능한 IP를 설정하고 80번이 아닌 별도의 포트를 사용하도록 한다.
. 관리자 페이지에 접속 시 추가인증을 요구하도록 해야 한다.
중앙 집중화된 접근제어를 제공하는 라이브러리나 프레임워크를 사용하여 각 종류의 자원에 대한 접근을 보호할 수 있다.
연관된 구현단계 보안 약점 항목
보안기능 : 부적절한 인가, 중요한 자원에 대한 잘못된 권한 설정
암호키 관리
암호키 생성,분배,접근,파기 등 안전하게 암호키 생명 주기별 암호키 관리방법을 안전하게 설계해야 한다.
보안대책
- DB데이터 암호화에 사용되는 암호키는 한국인터넷진흥원의 암호이용안내서에서 정의하고 있는 방법을 적용해야 한다.
- 설정파일(xml,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
취약점 개요
하드코드된 암호키
코드내부에 암호화 키를 하드코딩하여 암호화를 수행하면 암호화된 정보가 유출될 가능성이 높아진다.
주석문 안에 포함된 암호키
주석문 안에 암호키에 대한 설명이 포함되어 있는 경우 공격자가 소스코드에 접근할 우 있다면 아주 쉽게 암호키가 노출될 수 있다
설계시 고려사항
DB데이터 암호화에 사용되는 암호키는 한국인테넷 진흥원의 암호 키 관리 안내서 에서 정의하고 있는 방법을 적용해야 한다.
a. 암호키 관리 규칙 생성 시 고려사항
./ DB데이터 암호화에 사용되는 암호키는 데이터가 저장되는 데이터베이스와 물리적으로 분리된 장소에 별도로 보관한다.
./ 암호키를 생성, 분배, 사용, 폐기하는 키의 생명주기관리를 위한 명시적인 암호화 정책을 적용한다.
./ 패스워드나 암호화키는 메모리에 저장하지 않는다.
./ 패스워드나 암호키가 메모리에 저장되어야 하는 경우 사용종료 후 메모리를 0으로 초기화 한다.
./ 암호키 생성 및 변경 시 암호키에 대한 백업기능을 구현한다.
./ 암호알고리즘에 사용되는 키 종류에 따라 사용 유효기한을 설정한다.
b. 조직의 보호 목적에 따라 암호키 관리 수준을 지정
NIST에서 제정한 FIPS140-2의 레벨로써 조직의 보호목넉에 따라 적절히 채택한다.
./FIPS 140-2 레벨 분류
Level 1 : 암호모듈에 대한 기본적인 보안요구사항만을 충족하여 최소한의 보안을 제공
Level 2 : 침입자의 불법적인 접근을 방지하고 침입 이후에 변조에 나타내는 증거를 제공함으로써 물리적인 보안 메커니즘을 제공한다.
Level 3 : 강력한 변조 탐지 및 대응의 일환으로 침입을 감지하면 저장된 키를 삭제한다.
Level 4 : 암호모듈 외부의 전압이나 온도 등을 감지하여 슈퍼쿨링(Supercooling)등 환경의 이상변화 시 암호키를 삭제한다.
c. 키 생명주기 기준 암호화 키 관리 프로세스를 구축
./ 키 생성 – 암호화 키와 패스워드를 생성 사용 관리하는 사람 등을 명시하고 키를 생성하는데 사용하는 프로그램 등 어떠한 방법으로
생성하는지에 대한 절차를 명시
./ 키 사용 – 암호화 키와 패스워드를 어떠한 방법으로 사용하는지에 대한 절차, 생성한 키의 종류레 따른 변경주기, 인가된 사용자만 키에
접근할 수 있는 접근통제 방법 및 요구사항 등을 명시한다.
./ 키 폐기 – 키의 사용주기가 다 된 경우 및 사용 용도가 끝난 경우 등 생성한 키를 폐기하여야 하는 경우를 명시하고 암호화 키와 패스워드를
안전하게 폐기하는 절차 및 요구사항 등을 명시한다.
d. 키 복구 방안
사용자 퇴사 등으로 인한 사용자 이외의 사람에게 키 복구가 필요한 경우 암호화 키는 정보보호 담당자의 관리 하에 암호화 키 관리대장 등에서
복구하고 패스워드는 정보보보 담당자가 임시 패스워드를 발급하는 등 키 복구에 대한 방안을 마련한다.
e. 암호키 사용 유효기간
암 복호화 키의 사용이 일정시간을 넘은 경우 사용자 인터페이스로 키 사용기간이 경과했음을 알리고 새로운 키 생성을 권장하도록 설계한다
NIST 권고안의 암호키 사용 유효기간
대칭키 암호 알고리즘 : 송신자 사용기간은 최대 2년, 수신자 사용기간은 (송신자 사용기간 +3 년 ) 이하
공개키 암호 알고리즘 : 암호화 공개키 최대 2년
복호화 개인키 최대 2년
서명용 개인키 1-3년
검증용 공개키 키 크기에 따라 다름
설정 파일(XML,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
설정파일내의 중요 정보 암호화에 사용된 암호키는 마스터키를 이용하여 암호화 하여 별도의 디렉토리에 보관한다.중요자원(프로그램 설정, 민감한 사용자 데이터 등)을 정의하고 정의된 중요자원에 대한 접근을
통제하는 신뢰할 수 있는 방법(권한 관리 포함) 및 접근 통제 실패 시 대응방안을 설계해야 한다.
보안대책
- 중요자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
- 중요기능에 대한 접근통제 정책을 수립하여 정굥해야 한다.
- 관리자 페이지에 대한 접근통제 정책을 수립하여 적용해야 한다.
취약점 개요
- 관리자 페이지 노출
관리자 페이지가 인터넷으로 접근 가능할 경우 해당 페이지는 공격자의 주 공격대상으로 SQL삽입,
무차별대입 공격 등 다양한 형태의 공격의 빌미를 제공하게 되는 취약점이다.
- SSI 삽입
SSI(Server-side Includes)는 HTML 문서 내 변수 값으로 입력된 후 이를 서버가 처리하게 되는데
이 때 인젝션 명령문이 수행되어 서버 데이터 정보가 누출되는 취약점이다.
Exec cmd=”ls –la” 를 특정 데이터에 입력 하여 서버로 전송
- 부적절한 인가
프로그램이 모든 가능한 실행경로에 대해서 접근제어를 검사하지 않거나 불완전하게 검사하는경우
공격자는 접근 가능한 실행경로로 정보를 유출할 수 있는 취약점
- 중요자원에 대한 잘못된 권한 설정
소프트웨어가 중요한 보안 관련자원에 대하여 읽기, 수정 등의 권한을 의도하지 않게 허가할 경우 권한을
갖지 않은 사용자가 해당 자원을 사용하게 될 수 있는 취약점이다.
설계 시 고려사항
RBAC(역할기반 접근제어) 모델을 사용하여 기업, 정보 등 다수의 사용자와 정보객체들로 구성된 조직체계에서 사용자에게
할당된 역할을 기반으로 권한을 부여하도록 설계한다.
접근제어목록(Access Control List)을 구성하여 자원에 대한 접근 권한을 설정한다.
예를 들면 Spring Security 프레임워크 사용 시 ACL 모듈을 추가할 수 있다
a. 모든 도메인 객체에 대한 ACL엔트리를 효과적으로 검색하고 수정한다.
b. 메소드 호출에 앞서 각 사용자가 객체에 대해 특절 작업을 수행할 권한이 있는지 검증한다
c. 메소드 호추이 끝난 후 각 사용자가 객체(또는 반환되는 객체)에 대해 특정 작업을 수행할 권한이 있는지 검증한다.
./ 중요 자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
중요자원에 대한 접근권한을 최소권한으로 설정한다.
중요자원에 대한 접근 통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
중요자원(파일,프로세스,메모리,데이터베이스 등)에 대한 접근을 통제하기 위해 ACL이나 RBAC을 적용하도록 설계
접근통제 정책을 수립할 때는 최소권한의 원칙과 권한 분리 정책에 따라 자원에 대한 권한을 할당하고 자원에 대한
접근은 요구 조건을 충족할 때만 허가하도록 설계해야 한다.
./ 중요기능에 대한 접근통제 정책을 수립하여 적용해야 한다.
주요기능에 대한 접근 통제는 소프트웨어를 익명 일반 특권사용자와 관리자 영역으로 구분하여 역할 기반 접근통제(RBAC) 정책
및 비즈니스 로직에 따라 접근통제가 실시 되도록 다음과 같은 조건에 따라 설계한다.
. 중요기능에 대한 접근권한은 최소권한으로 설정한다.
. 중요기능에 대한 접근통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
. 프로그램에서 사용자 또는 자원에 대한 권한의 할당, 수정, 확인, 검사를 수행하여 의도치 않은 범위의 권한을 획득하지 않도록 한다.
. 파라미터 변조로 인증이 올바르게 수행되지 않을 수 있으므로 파라미터가 변조되지 않았는지 확인하는 절차를 구현한다.
. 상위권한을 사용해 수행되는 기능을 구현해야 하는 경우 권한상승은 가능한 가장 마지막에 수행하고 수행 종료 즉시 원상 복귀한다.
./ 관라자 페이지에 대한 접근 통제 정책을 수립하여 적용해야 한다.
. 관리자 페이지의 URL은 쉽게 추측할 수 없도록 설정한다.
. 관라지 페이지 접속 시 암호화 통신 채널(TLS 등)을 사용해야 한다.
. 관리자 페이지에 접속 가능한 IP를 설정하고 80번이 아닌 별도의 포트를 사용하도록 한다.
. 관리자 페이지에 접속 시 추가인증을 요구하도록 해야 한다.
중앙 집중화된 접근제어를 제공하는 라이브러리나 프레임워크를 사용하여 각 종류의 자원에 대한 접근을 보호할 수 있다.
연관된 구현단계 보안 약점 항목
보안기능 : 부적절한 인가, 중요한 자원에 대한 잘못된 권한 설정
암호키 관리
암호키 생성,분배,접근,파기 등 안전하게 암호키 생명 주기별 암호키 관리방법을 안전하게 설계해야 한다.
보안대책
- DB데이터 암호화에 사용되는 암호키는 한국인터넷진흥원의 암호이용안내서에서 정의하고 있는 방법을 적용해야 한다.
- 설정파일(xml,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
취약점 개요
하드코드된 암호키
코드내부에 암호화 키를 하드코딩하여 암호화를 수행하면 암호화된 정보가 유출될 가능성이 높아진다.
주석문 안에 포함된 암호키
주석문 안에 암호키에 대한 설명이 포함되어 있는 경우 공격자가 소스코드에 접근할 우 있다면 아주 쉽게 암호키가 노출될 수 있다
설계시 고려사항
DB데이터 암호화에 사용되는 암호키는 한국인테넷 진흥원의 암호 키 관리 안내서 에서 정의하고 있는 방법을 적용해야 한다.
a. 암호키 관리 규칙 생성 시 고려사항
./ DB데이터 암호화에 사용되는 암호키는 데이터가 저장되는 데이터베이스와 물리적으로 분리된 장소에 별도로 보관한다.
./ 암호키를 생성, 분배, 사용, 폐기하는 키의 생명주기관리를 위한 명시적인 암호화 정책을 적용한다.
./ 패스워드나 암호화키는 메모리에 저장하지 않는다.
./ 패스워드나 암호키가 메모리에 저장되어야 하는 경우 사용종료 후 메모리를 0으로 초기화 한다.
./ 암호키 생성 및 변경 시 암호키에 대한 백업기능을 구현한다.
./ 암호알고리즘에 사용되는 키 종류에 따라 사용 유효기한을 설정한다.
b. 조직의 보호 목적에 따라 암호키 관리 수준을 지정
NIST에서 제정한 FIPS140-2의 레벨로써 조직의 보호목넉에 따라 적절히 채택한다.
./FIPS 140-2 레벨 분류
Level 1 : 암호모듈에 대한 기본적인 보안요구사항만을 충족하여 최소한의 보안을 제공
Level 2 : 침입자의 불법적인 접근을 방지하고 침입 이후에 변조에 나타내는 증거를 제공함으로써 물리적인 보안 메커니즘을 제공한다.
Level 3 : 강력한 변조 탐지 및 대응의 일환으로 침입을 감지하면 저장된 키를 삭제한다.
Level 4 : 암호모듈 외부의 전압이나 온도 등을 감지하여 슈퍼쿨링(Supercooling)등 환경의 이상변화 시 암호키를 삭제한다.
c. 키 생명주기 기준 암호화 키 관리 프로세스를 구축
./ 키 생성 – 암호화 키와 패스워드를 생성 사용 관리하는 사람 등을 명시하고 키를 생성하는데 사용하는 프로그램 등 어떠한 방법으로
생성하는지에 대한 절차를 명시
./ 키 사용 – 암호화 키와 패스워드를 어떠한 방법으로 사용하는지에 대한 절차, 생성한 키의 종류레 따른 변경주기, 인가된 사용자만 키에
접근할 수 있는 접근통제 방법 및 요구사항 등을 명시한다.
./ 키 폐기 – 키의 사용주기가 다 된 경우 및 사용 용도가 끝난 경우 등 생성한 키를 폐기하여야 하는 경우를 명시하고 암호화 키와 패스워드를
안전하게 폐기하는 절차 및 요구사항 등을 명시한다.
d. 키 복구 방안
사용자 퇴사 등으로 인한 사용자 이외의 사람에게 키 복구가 필요한 경우 암호화 키는 정보보호 담당자의 관리 하에 암호화 키 관리대장 등에서
복구하고 패스워드는 정보보보 담당자가 임시 패스워드를 발급하는 등 키 복구에 대한 방안을 마련한다.
e. 암호키 사용 유효기간
암 복호화 키의 사용이 일정시간을 넘은 경우 사용자 인터페이스로 키 사용기간이 경과했음을 알리고 새로운 키 생성을 권장하도록 설계한다
NIST 권고안의 암호키 사용 유효기간
대칭키 암호 알고리즘 : 송신자 사용기간은 최대 2년, 수신자 사용기간은 (송신자 사용기간 +3 년 ) 이하
공개키 암호 알고리즘 : 암호화 공개키 최대 2년
복호화 개인키 최대 2년
서명용 개인키 1-3년
검증용 공개키 키 크기에 따라 다름
설정 파일(XML,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
설정파일내의 중요 정보 암호화에 사용된 암호키는 마스터키를 이용하여 암호화 하여 별도의 디렉토리에 보관한다.통제하는 신뢰할 수 있는 방법(권한 관리 포함) 및 접근 통제 실패 시 대응방안을 설계해야 한다.
보안대책
- 중요자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
- 중요기능에 대한 접근통제 정책을 수립하여 정굥해야 한다.
- 관리자 페이지에 대한 접근통제 정책을 수립하여 적용해야 한다.
취약점 개요
- 관리자 페이지 노출
관리자 페이지가 인터넷으로 접근 가능할 경우 해당 페이지는 공격자의 주 공격대상으로 SQL삽입,
무차별대입 공격 등 다양한 형태의 공격의 빌미를 제공하게 되는 취약점이다.
- SSI 삽입
SSI(Server-side Includes)는 HTML 문서 내 변수 값으로 입력된 후 이를 서버가 처리하게 되는데
이 때 인젝션 명령문이 수행되어 서버 데이터 정보가 누출되는 취약점이다.
Exec cmd=”ls –la” 를 특정 데이터에 입력 하여 서버로 전송
- 부적절한 인가
프로그램이 모든 가능한 실행경로에 대해서 접근제어를 검사하지 않거나 불완전하게 검사하는경우
공격자는 접근 가능한 실행경로로 정보를 유출할 수 있는 취약점
- 중요자원에 대한 잘못된 권한 설정
소프트웨어가 중요한 보안 관련자원에 대하여 읽기, 수정 등의 권한을 의도하지 않게 허가할 경우 권한을
갖지 않은 사용자가 해당 자원을 사용하게 될 수 있는 취약점이다.
설계 시 고려사항
RBAC(역할기반 접근제어) 모델을 사용하여 기업, 정보 등 다수의 사용자와 정보객체들로 구성된 조직체계에서 사용자에게
할당된 역할을 기반으로 권한을 부여하도록 설계한다.
접근제어목록(Access Control List)을 구성하여 자원에 대한 접근 권한을 설정한다.
예를 들면 Spring Security 프레임워크 사용 시 ACL 모듈을 추가할 수 있다
a. 모든 도메인 객체에 대한 ACL엔트리를 효과적으로 검색하고 수정한다.
b. 메소드 호출에 앞서 각 사용자가 객체에 대해 특절 작업을 수행할 권한이 있는지 검증한다
c. 메소드 호추이 끝난 후 각 사용자가 객체(또는 반환되는 객체)에 대해 특정 작업을 수행할 권한이 있는지 검증한다.
./ 중요 자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
중요자원에 대한 접근권한을 최소권한으로 설정한다.
중요자원에 대한 접근 통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
중요자원(파일,프로세스,메모리,데이터베이스 등)에 대한 접근을 통제하기 위해 ACL이나 RBAC을 적용하도록 설계
접근통제 정책을 수립할 때는 최소권한의 원칙과 권한 분리 정책에 따라 자원에 대한 권한을 할당하고 자원에 대한
접근은 요구 조건을 충족할 때만 허가하도록 설계해야 한다.
./ 중요기능에 대한 접근통제 정책을 수립하여 적용해야 한다.
주요기능에 대한 접근 통제는 소프트웨어를 익명 일반 특권사용자와 관리자 영역으로 구분하여 역할 기반 접근통제(RBAC) 정책
및 비즈니스 로직에 따라 접근통제가 실시 되도록 다음과 같은 조건에 따라 설계한다.
. 중요기능에 대한 접근권한은 최소권한으로 설정한다.
. 중요기능에 대한 접근통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
. 프로그램에서 사용자 또는 자원에 대한 권한의 할당, 수정, 확인, 검사를 수행하여 의도치 않은 범위의 권한을 획득하지 않도록 한다.
. 파라미터 변조로 인증이 올바르게 수행되지 않을 수 있으므로 파라미터가 변조되지 않았는지 확인하는 절차를 구현한다.
. 상위권한을 사용해 수행되는 기능을 구현해야 하는 경우 권한상승은 가능한 가장 마지막에 수행하고 수행 종료 즉시 원상 복귀한다.
./ 관라자 페이지에 대한 접근 통제 정책을 수립하여 적용해야 한다.
. 관리자 페이지의 URL은 쉽게 추측할 수 없도록 설정한다.
. 관라지 페이지 접속 시 암호화 통신 채널(TLS 등)을 사용해야 한다.
. 관리자 페이지에 접속 가능한 IP를 설정하고 80번이 아닌 별도의 포트를 사용하도록 한다.
. 관리자 페이지에 접속 시 추가인증을 요구하도록 해야 한다.
중앙 집중화된 접근제어를 제공하는 라이브러리나 프레임워크를 사용하여 각 종류의 자원에 대한 접근을 보호할 수 있다.
연관된 구현단계 보안 약점 항목
보안기능 : 부적절한 인가, 중요한 자원에 대한 잘못된 권한 설정
암호키 관리
암호키 생성,분배,접근,파기 등 안전하게 암호키 생명 주기별 암호키 관리방법을 안전하게 설계해야 한다.
보안대책
- DB데이터 암호화에 사용되는 암호키는 한국인터넷진흥원의 암호이용안내서에서 정의하고 있는 방법을 적용해야 한다.
- 설정파일(xml,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
취약점 개요
하드코드된 암호키
코드내부에 암호화 키를 하드코딩하여 암호화를 수행하면 암호화된 정보가 유출될 가능성이 높아진다.
주석문 안에 포함된 암호키
주석문 안에 암호키에 대한 설명이 포함되어 있는 경우 공격자가 소스코드에 접근할 우 있다면 아주 쉽게 암호키가 노출될 수 있다
설계시 고려사항
DB데이터 암호화에 사용되는 암호키는 한국인테넷 진흥원의 암호 키 관리 안내서 에서 정의하고 있는 방법을 적용해야 한다.
a. 암호키 관리 규칙 생성 시 고려사항
./ DB데이터 암호화에 사용되는 암호키는 데이터가 저장되는 데이터베이스와 물리적으로 분리된 장소에 별도로 보관한다.
./ 암호키를 생성, 분배, 사용, 폐기하는 키의 생명주기관리를 위한 명시적인 암호화 정책을 적용한다.
./ 패스워드나 암호화키는 메모리에 저장하지 않는다.
./ 패스워드나 암호키가 메모리에 저장되어야 하는 경우 사용종료 후 메모리를 0으로 초기화 한다.
./ 암호키 생성 및 변경 시 암호키에 대한 백업기능을 구현한다.
./ 암호알고리즘에 사용되는 키 종류에 따라 사용 유효기한을 설정한다.
b. 조직의 보호 목적에 따라 암호키 관리 수준을 지정
NIST에서 제정한 FIPS140-2의 레벨로써 조직의 보호목넉에 따라 적절히 채택한다.
./FIPS 140-2 레벨 분류
Level 1 : 암호모듈에 대한 기본적인 보안요구사항만을 충족하여 최소한의 보안을 제공
Level 2 : 침입자의 불법적인 접근을 방지하고 침입 이후에 변조에 나타내는 증거를 제공함으로써 물리적인 보안 메커니즘을 제공한다.
Level 3 : 강력한 변조 탐지 및 대응의 일환으로 침입을 감지하면 저장된 키를 삭제한다.
Level 4 : 암호모듈 외부의 전압이나 온도 등을 감지하여 슈퍼쿨링(Supercooling)등 환경의 이상변화 시 암호키를 삭제한다.
c. 키 생명주기 기준 암호화 키 관리 프로세스를 구축
./ 키 생성 – 암호화 키와 패스워드를 생성 사용 관리하는 사람 등을 명시하고 키를 생성하는데 사용하는 프로그램 등 어떠한 방법으로
생성하는지에 대한 절차를 명시
./ 키 사용 – 암호화 키와 패스워드를 어떠한 방법으로 사용하는지에 대한 절차, 생성한 키의 종류레 따른 변경주기, 인가된 사용자만 키에
접근할 수 있는 접근통제 방법 및 요구사항 등을 명시한다.
./ 키 폐기 – 키의 사용주기가 다 된 경우 및 사용 용도가 끝난 경우 등 생성한 키를 폐기하여야 하는 경우를 명시하고 암호화 키와 패스워드를
안전하게 폐기하는 절차 및 요구사항 등을 명시한다.
d. 키 복구 방안
사용자 퇴사 등으로 인한 사용자 이외의 사람에게 키 복구가 필요한 경우 암호화 키는 정보보호 담당자의 관리 하에 암호화 키 관리대장 등에서
복구하고 패스워드는 정보보보 담당자가 임시 패스워드를 발급하는 등 키 복구에 대한 방안을 마련한다.
e. 암호키 사용 유효기간
암 복호화 키의 사용이 일정시간을 넘은 경우 사용자 인터페이스로 키 사용기간이 경과했음을 알리고 새로운 키 생성을 권장하도록 설계한다
NIST 권고안의 암호키 사용 유효기간
대칭키 암호 알고리즘 : 송신자 사용기간은 최대 2년, 수신자 사용기간은 (송신자 사용기간 +3 년 ) 이하
공개키 암호 알고리즘 : 암호화 공개키 최대 2년
복호화 개인키 최대 2년
서명용 개인키 1-3년
검증용 공개키 키 크기에 따라 다름
설정 파일(XML,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
설정파일내의 중요 정보 암호화에 사용된 암호키는 마스터키를 이용하여 암호화 하여 별도의 디렉토리에 보관한다.
보안대책
- 중요자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
- 중요기능에 대한 접근통제 정책을 수립하여 정굥해야 한다.
- 관리자 페이지에 대한 접근통제 정책을 수립하여 적용해야 한다.
취약점 개요
- 관리자 페이지 노출
관리자 페이지가 인터넷으로 접근 가능할 경우 해당 페이지는 공격자의 주 공격대상으로 SQL삽입,
무차별대입 공격 등 다양한 형태의 공격의 빌미를 제공하게 되는 취약점이다.
- SSI 삽입
SSI(Server-side Includes)는 HTML 문서 내 변수 값으로 입력된 후 이를 서버가 처리하게 되는데
이 때 인젝션 명령문이 수행되어 서버 데이터 정보가 누출되는 취약점이다.
Exec cmd=”ls –la” 를 특정 데이터에 입력 하여 서버로 전송
- 부적절한 인가
프로그램이 모든 가능한 실행경로에 대해서 접근제어를 검사하지 않거나 불완전하게 검사하는경우
공격자는 접근 가능한 실행경로로 정보를 유출할 수 있는 취약점
- 중요자원에 대한 잘못된 권한 설정
소프트웨어가 중요한 보안 관련자원에 대하여 읽기, 수정 등의 권한을 의도하지 않게 허가할 경우 권한을
갖지 않은 사용자가 해당 자원을 사용하게 될 수 있는 취약점이다.
설계 시 고려사항
RBAC(역할기반 접근제어) 모델을 사용하여 기업, 정보 등 다수의 사용자와 정보객체들로 구성된 조직체계에서 사용자에게
할당된 역할을 기반으로 권한을 부여하도록 설계한다.
접근제어목록(Access Control List)을 구성하여 자원에 대한 접근 권한을 설정한다.
예를 들면 Spring Security 프레임워크 사용 시 ACL 모듈을 추가할 수 있다
a. 모든 도메인 객체에 대한 ACL엔트리를 효과적으로 검색하고 수정한다.
b. 메소드 호출에 앞서 각 사용자가 객체에 대해 특절 작업을 수행할 권한이 있는지 검증한다
c. 메소드 호추이 끝난 후 각 사용자가 객체(또는 반환되는 객체)에 대해 특정 작업을 수행할 권한이 있는지 검증한다.
./ 중요 자원에 대한 접근통제 정책을 수립하여 적용해야 한다.
중요자원에 대한 접근권한을 최소권한으로 설정한다.
중요자원에 대한 접근 통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
중요자원(파일,프로세스,메모리,데이터베이스 등)에 대한 접근을 통제하기 위해 ACL이나 RBAC을 적용하도록 설계
접근통제 정책을 수립할 때는 최소권한의 원칙과 권한 분리 정책에 따라 자원에 대한 권한을 할당하고 자원에 대한
접근은 요구 조건을 충족할 때만 허가하도록 설계해야 한다.
./ 중요기능에 대한 접근통제 정책을 수립하여 적용해야 한다.
주요기능에 대한 접근 통제는 소프트웨어를 익명 일반 특권사용자와 관리자 영역으로 구분하여 역할 기반 접근통제(RBAC) 정책
및 비즈니스 로직에 따라 접근통제가 실시 되도록 다음과 같은 조건에 따라 설계한다.
. 중요기능에 대한 접근권한은 최소권한으로 설정한다.
. 중요기능에 대한 접근통제 정책을 설정하고 사용자별 또는 그룹별 접근을 체크한다.
. 프로그램에서 사용자 또는 자원에 대한 권한의 할당, 수정, 확인, 검사를 수행하여 의도치 않은 범위의 권한을 획득하지 않도록 한다.
. 파라미터 변조로 인증이 올바르게 수행되지 않을 수 있으므로 파라미터가 변조되지 않았는지 확인하는 절차를 구현한다.
. 상위권한을 사용해 수행되는 기능을 구현해야 하는 경우 권한상승은 가능한 가장 마지막에 수행하고 수행 종료 즉시 원상 복귀한다.
./ 관라자 페이지에 대한 접근 통제 정책을 수립하여 적용해야 한다.
. 관리자 페이지의 URL은 쉽게 추측할 수 없도록 설정한다.
. 관라지 페이지 접속 시 암호화 통신 채널(TLS 등)을 사용해야 한다.
. 관리자 페이지에 접속 가능한 IP를 설정하고 80번이 아닌 별도의 포트를 사용하도록 한다.
. 관리자 페이지에 접속 시 추가인증을 요구하도록 해야 한다.
중앙 집중화된 접근제어를 제공하는 라이브러리나 프레임워크를 사용하여 각 종류의 자원에 대한 접근을 보호할 수 있다.
연관된 구현단계 보안 약점 항목
보안기능 : 부적절한 인가, 중요한 자원에 대한 잘못된 권한 설정
암호키 관리
암호키 생성,분배,접근,파기 등 안전하게 암호키 생명 주기별 암호키 관리방법을 안전하게 설계해야 한다.
보안대책
- DB데이터 암호화에 사용되는 암호키는 한국인터넷진흥원의 암호이용안내서에서 정의하고 있는 방법을 적용해야 한다.
- 설정파일(xml,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
취약점 개요
하드코드된 암호키
코드내부에 암호화 키를 하드코딩하여 암호화를 수행하면 암호화된 정보가 유출될 가능성이 높아진다.
주석문 안에 포함된 암호키
주석문 안에 암호키에 대한 설명이 포함되어 있는 경우 공격자가 소스코드에 접근할 우 있다면 아주 쉽게 암호키가 노출될 수 있다
설계시 고려사항
DB데이터 암호화에 사용되는 암호키는 한국인테넷 진흥원의 암호 키 관리 안내서 에서 정의하고 있는 방법을 적용해야 한다.
a. 암호키 관리 규칙 생성 시 고려사항
./ DB데이터 암호화에 사용되는 암호키는 데이터가 저장되는 데이터베이스와 물리적으로 분리된 장소에 별도로 보관한다.
./ 암호키를 생성, 분배, 사용, 폐기하는 키의 생명주기관리를 위한 명시적인 암호화 정책을 적용한다.
./ 패스워드나 암호화키는 메모리에 저장하지 않는다.
./ 패스워드나 암호키가 메모리에 저장되어야 하는 경우 사용종료 후 메모리를 0으로 초기화 한다.
./ 암호키 생성 및 변경 시 암호키에 대한 백업기능을 구현한다.
./ 암호알고리즘에 사용되는 키 종류에 따라 사용 유효기한을 설정한다.
b. 조직의 보호 목적에 따라 암호키 관리 수준을 지정
NIST에서 제정한 FIPS140-2의 레벨로써 조직의 보호목넉에 따라 적절히 채택한다.
./FIPS 140-2 레벨 분류
Level 1 : 암호모듈에 대한 기본적인 보안요구사항만을 충족하여 최소한의 보안을 제공
Level 2 : 침입자의 불법적인 접근을 방지하고 침입 이후에 변조에 나타내는 증거를 제공함으로써 물리적인 보안 메커니즘을 제공한다.
Level 3 : 강력한 변조 탐지 및 대응의 일환으로 침입을 감지하면 저장된 키를 삭제한다.
Level 4 : 암호모듈 외부의 전압이나 온도 등을 감지하여 슈퍼쿨링(Supercooling)등 환경의 이상변화 시 암호키를 삭제한다.
c. 키 생명주기 기준 암호화 키 관리 프로세스를 구축
./ 키 생성 – 암호화 키와 패스워드를 생성 사용 관리하는 사람 등을 명시하고 키를 생성하는데 사용하는 프로그램 등 어떠한 방법으로
생성하는지에 대한 절차를 명시
./ 키 사용 – 암호화 키와 패스워드를 어떠한 방법으로 사용하는지에 대한 절차, 생성한 키의 종류레 따른 변경주기, 인가된 사용자만 키에
접근할 수 있는 접근통제 방법 및 요구사항 등을 명시한다.
./ 키 폐기 – 키의 사용주기가 다 된 경우 및 사용 용도가 끝난 경우 등 생성한 키를 폐기하여야 하는 경우를 명시하고 암호화 키와 패스워드를
안전하게 폐기하는 절차 및 요구사항 등을 명시한다.
d. 키 복구 방안
사용자 퇴사 등으로 인한 사용자 이외의 사람에게 키 복구가 필요한 경우 암호화 키는 정보보호 담당자의 관리 하에 암호화 키 관리대장 등에서
복구하고 패스워드는 정보보보 담당자가 임시 패스워드를 발급하는 등 키 복구에 대한 방안을 마련한다.
e. 암호키 사용 유효기간
암 복호화 키의 사용이 일정시간을 넘은 경우 사용자 인터페이스로 키 사용기간이 경과했음을 알리고 새로운 키 생성을 권장하도록 설계한다
NIST 권고안의 암호키 사용 유효기간
대칭키 암호 알고리즘 : 송신자 사용기간은 최대 2년, 수신자 사용기간은 (송신자 사용기간 +3 년 ) 이하
공개키 암호 알고리즘 : 암호화 공개키 최대 2년
복호화 개인키 최대 2년
서명용 개인키 1-3년
검증용 공개키 키 크기에 따라 다름
설정 파일(XML,Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.
설정파일내의 중요 정보 암호화에 사용된 암호키는 마스터키를 이용하여 암호화 하여 별도의 디렉토리에 보관한다.
HTTP Only 와 Secure Cookie 20220905 (0) | 2022.09.05 |
---|---|
암호연산 20220902 (0) | 2022.09.02 |
인증대상 및 방식 (0) | 2022.08.27 |
[KISA Insight 2022 Vol.04] 메타버스와 NFT, 사이버보안 위협 전망 및 분석 (1) | 2022.08.20 |
보안 DBMS 조회 및 결과 검증 20220811 (0) | 2022.08.11 |
댓글 영역