신뢰할 수 있는 디자인
Categories:
보안 아키텍처 및 설계 원칙
보안 3요소와 보안 설계 원칙
- 무결성 Integrity
- 가용성 Availability
- 기밀성 Confidentiality
개방형 설계 원칙
Open Design
- 설계는 비밀이 되어서는 안 되며, 개방된 설계가 더 안전합니다.
- 보안은 비밀 유지에 의존하지 않습니다.
실패-기본값 보안 원칙
Fail-safe defaults
- 접근 결정은 “허용"에 기반해야 하며, “거부"에 기반해서는 안 됩니다.
- 기본적으로 접근을 허용하지 않으며, 보호 메커니즘은 허용된 접근 상황을 식별하는 데만 사용됩니다.
- 실패 안전: 복잡한 시스템은 기능이 실패했을 때 비상 안전 메커니즘을 가져야 하며, 오류 메시지와 로그에 대해 조심해야 하여 정보 유출을 방지해야 합니다.
- 기본값 보안: 시스템이 초기 상태에서 기본 구성이 안전하도록 하며, 최소한의 시스템과 서비스를 제공하여 최대의 보안을 제공합니다.
권한 분리 원칙
Separation of Privilege
- 한 보호 메커니즘을 해제하기 위해 두 개의 열쇠가 필요한 것이 한 개의 열쇠를 사용하는 것보다 더 강건하고 더 유연합니다.
- 권한 분리의 목적
- 이해 충돌과 개별 권력 남용을 방지
- 중요한 권한을 여러 권한으로 분해하여 보호 대상이 불법적으로 획득되기 어렵게 만들고, 이를 통해 더 안전하게 만듭니다.
- 서로 다른 프로세스의 권한과 책임을 분리
시스템은 기본적으로 3개의 역할을 설정할 수 있으며, 역할 간 시스템 계정 권한은 서로 독립적이고 권한과 책임이 분리됩니다:
- 시스템 관리자: 시스템의 일상적인 사용자 관리, 구성 관리를 담당
- 보안 관리자: 사용자 상태, 보안 구성의 활성화, 비활성화 관리를 담당
- 보안 감사자: 앞의 두 역할의 작업에 대한 로그 감사를 담당하며 로그 내보내기 권한을 가지고 있어 시스템 사용자의 모든 작업을 추적할 수 있도록 보장
최소 권한 원칙
Least Privilege
- 시스템의 모든 사용자, 모든 프로그램은 작업을 수행하기 위해 최소한 필수적인 권한 세트만을 사용해야 합니다.
- 애플리케이션이 최소 권한으로 실행되도록 보장
- 데이터베이스, 웹 서버 등 시스템의 각 사용자가 실행하는 다양한 프로그램에 대해서는 시스템 최고 권한 계정이 아닌 최소 권한 계정으로 실행되거나 연결되도록 주의
- 새 계정을 생성할 때 기본적으로 최소 권한 역할을 부여
경제적 사용 원칙
Economy of Mechanism
- 시스템 설계와 코드를 가능한 한 간단하고 간결하게 유지
- 소프트웨어 설계가 복잡할수록 코드에 버그가 발생할 확률이 높아지며, 설계를 가능한 한 정교하게 할수록 보안 문제가 발생할 확률이 적어집니다.
- 필요하지 않은 중복 코드와 기능 모듈을 삭제하면 해당 코드를 유지하는 것은 시스템의 공격 표면을 증가시킬 뿐입니다.
- 중복 코드를 줄이기 위해 재사용 가능한 컴포넌트를 설계
- 경제적 적용: 간단하고 정교하며 컴포넌트화
- 과도한 설계 금지
최소 공통화 원칙
Least Common Mechanism
- 여러 객체가 동일한 리소스를 공유하는 시나리오를 피하고, 리소스 접근 공유 수량과 사용을 가능한 한 최소화해야 합니다.
- 공유 객체는 정보 흐름과 의도하지 않은 상호작용의 잠재적 위험 채널을 제공하므로 여러 객체가 동일한 리소스를 공유하는 시나리오를 피해야 합니다.
- 하나 또는 여러 객체가 공유 메커니즘이 제공하는 서비스에 만족하지 않는다면, 다른 객체의 버그에 의해 간접적으로 공격당하는 것을 방지하기 위해 공유 메커니즘을 사용하지 않을 수 있습니다.
- 공유 메모리 최소화
- 포트 바인딩 최소화
- 연결 감소, DoS 공격 방어
완전 중재 원칙
Complete Mediation
- 완전 중재 원칙은 각 객체에 대한 모든 접근이 보안 검증을 거쳐야 한다고 요구합니다.
- 주체가 객체에 접근하려고 할 때 시스템은 매번 주체가 해당 권한을 가지고 있는지 확인합니다.
- 가능한 한 자원 소유자가 접근 통제 결정을 내리도록 하며, 예를 들어 URL인 경우 백엔드 서버에서 확인하고 프런트엔드에서 판단하지 않도록 합니다.
- 캐시 사용과 검증에 특히 주의해야 하며, 캐시된 정보가 해커에 의해 변조되지 않았다는 것을 보장할 수 없습니다. 예: DNS 캐시 스푸핑.
심리적 수용 원칙
Psychological Acceptability
- 보안 메커니즘이 사용자에게 추가 부담을 줄 수 있지만, 이 부담은 최소한이어야 하며 합리적이어야 합니다.
- 보안 메커니즘은 시스템 사용자에게尽可能 친숙해야 하며, 시스템 사용과 이해를 용이하게 해야 합니다.
- 구성 방법이 지나치게 복잡하고 번거롭다면 시스템 관리자가 실수로 잘못된 옵션을 구성하여 시스템이 불안전해질 수 있습니다.
- 이 원칙은 일반적으로 인간-컴퓨터 상호작용, UCD(User Centered Design) 인터페이스와 관련됩니다.
다계층 방어 원칙
Defense in Depth 다계층 방어는 종합적인 요구 사항이 매우 높은 방어 원칙으로, 일반적으로 시스템 아키텍트가 다른 다양한 보안 설계 원칙을 종합적으로 활용하여 다중, 다중의 보안 검증 메커니즘을 채택하고, 시스템 아키텍처 수준에서 전체 시스템 수준의 보안 방어 메커니즘을 종합적으로 고려해야 하며, 단일 보안 메커니즘에만 의존해서는 안 됩니다.