보안 디자인 원칙
Open Design(개방형 디자인)
- 시스템의 설계 및 구현의 세부 사항이 외부에 알려질 수 있음을 가정하고 소프트웨어를 개발해야한다.
- 소프트웨어의 보안은 설계 및 구현의 비밀성에 의존해서는 안된다.
- 시스템의 보안이 설계나 구현의 세부 사항의 기밀성에 의존적이라면, 설계나 구현의 세부 사항을 알고 있는 공격자에 의해 보안 메커니즘이 무력화 될 수 있다.
- 해당 원칙은 정보(패스워드, 암호화 키)에는 적용되지 않는다.
2차 세계대전 당시 독일군은 에그니마라는 장비를 이용하여 암호화된 통신을 하였다. 당시 독일군이 사용한 에그니마는 그 구조와 원리가 알려져 있지 않았기 때문에, 연합군은 독일군의 암호문을 해독하는데 많은 어려움을 겪었다. 하지만 영국군에 의해 크게 손상된 U-보트에서 입수한 에그니마 관련된 정보와 독일군의 크고 작은 실수로 인해 얻어진 정보를 바탕으로 연합군 측은 독일군이 사용하던 에그니마를 이용하여 생성된 암호문을 해독할 수 있게 되었다.
Defence in depth(심층방어)
- 방어 대책 중 하나가 공격을 방어하는데 실패하더라도 또 다른 방어 대책/수단에 의해 시스템이 보호될 수 있도록 다양한 방어 대책을 적용해야 한다.
- 각 방어 대책/수단은 유사한 것이 아닌 성향이 다른 것이어야 한다.
“버퍼 메모리에 대한 심층방어의 예”
Secure Coding » Data Execution Prevention(DEP) » Address Space Layout Randomization(ASLR)
Least Privilege(최소 권한의 법칙)
- 모든 프로그램/사용자들은 작업을 수행하기 위해 필요한 최소한의 권한만을 가지도록 제한해야 한다.
- 프로그램 또는 사용자가 필요 이상의 권한을 가지지 않도록 제한한다.
- 예측하지 못했던 에러나 보안 취약점으로 인한 피해를 경감시킬 수 있다.
- 높은 수준의 권한을 가지고 있는 프로세스/쓰레드의 개수 또는 높은 수준의 권한을 가지고 실행되는 코드의 양을 최소화하는 것은 시스템의 오용 가능성을 낮추는데 도움이 된다.
루트 권한을 가진 웹 서버 프로세스 vs 웹 서비스 권한을 가진 웹 서버 프로세스
Unix/Linux의 디렉토리 및 파일 권한 설정(파일 삭제는 디렉토리에서 떼어내는 것이므로 디렉토리의 권한을 따른다. 매우 주의해야 한다.)
Fail-Safe Defualt
- 시스템 혹은 소프트웨어에 문제가 생겼을 경우 기본적으로 안전한 방향으로 동작하도록 설계하는 원칙을 의미한다.
- 주체에게 오브젝트에 대한 접근 권한이 명백하게 주어지지 않은 경우, 해당 오브젝트에 대한 접근은 거부되어야 한다.
- 객체에 대한 허용 여부에 대한 판단은 exclusion이 아니라 permission에 기반을 두어야 한다.
전자석 자물쇠 방식의 보안 문들은 전원이 끊기면 저절로 열리도록 되어 있으며, 이는 화재를 염두한 설계이다
Complete Mediation
- 자원에 대한 접근 주체가 객체에 대한 접근 요청을 수행하는 매 경우마다 권한에 대한 조사가 이루어져야 한다는 원칙이다.
- 인증 결과에 대한 정보를 캐시한 후 이를 재사용해서는 안된다.
Separation Privilege(권한분리)
- 오브젝트에 대한 접근권한 부여는 하나의 조건에만 의지해서는 안된다.
- 권한을 가지고 있지 못한 주체가 조건 중 일부를 우회하여 오브젝트에 접근을 시도하더라도 다른 조건에 의해서 접근을 거부할 수 있어야 한다.
요청 주체가 알고 있는 것(계정/패스워드) + 요청 주체가 가지고 있는 것(OTP)을 이용한 다중 인증
Least Common Mechanism
- 서로 다른 권한을 가지고 있는 주체들 사이에 공유되고 있는 자원, 자원에 접근하기 위해 사용되는 메커니즘, 코드의 양을 최소화하여야 한다.
- 서로 다른 주체들 사이에 공유되고 있는 메커니즘은 주체들 사이의 정보 통로가 된다.
시스템에서 인터넷 모드/사설망 모드를 스위칭하기 위해 인터넷과 사설망 연결을 위한 이중 네트워크 카드를 사용하였으나, 메모리를 공유하여 사용하게 되면서 사설망 모드에서 사용된 기밀 정보가 유출되는 문제
Psychological Acceptabillity(심리적 용인성)
- 보안에서 가장 중요한 것은 사람이다.
- 보안 시스템의 사용자 인터페이스나 환경 설정 방법은 사용하기 쉽도록 설계되어야 한다.
- 보안 메커니즘으로 인해 시스템이나 자원의 사용이 보안 메커니즘이 제공되지 않을 때보다 더 어려워져서는 안된다.
- 보안 메커니즘의 적용을 위한 환경 설정이 어렵거나, 보안 시스템의 사용이 어려운 경우 사용자들은 보다 쉬운 방법(안전하지 못한)을 선택하는 경향이 강하다.
SSL/TLS 명세는 mandatory server side certificate와 optional client side certificate를 정의하고 있다. 가장 높은 수준의 보안을 위해서는 양 side 모두 사용이 되어야 하지만 client side certificate는 인증서를 설치하고 관리하는데 필요한 오버헤드로 인해 널리 사용되고 있지 못하다.
Economy of Mechanism
- 보안 메커니즘은 최대한 심플하게 구현되어야 한다.
- 일반적으로 메커니즘의 디자인이나 구현의 복잡도가 증가하면 취약점의 수도 증가한다.
- 메커니즘의 디자인이나 구현의 복잡도가 증가할수록 line-by-line 방식을 이용하여 시스템의 잠재적인 문제점을 분석하는 것이 더욱 어려워진다.
- 메커니즘의 디자인이나 구현의 복잡도가 증가할수록 발견된 문제점을 고치기 어려워진다.