보안 설계 패턴
패턴이란 - 잠재적인 위협을 처리하는 도구 상자
패턴을 적용할 시에는 필요성과 단순성을 고려하고 과용하면 안된다.(오버헤드의 위험이 있음)
1. 설계 속성 패턴 그룹
전체적인 관점에서 설계가 어떻게 보이는지를 설명
- 설계의 경제성 패턴: 설계가 단순해야한다.(단순할수록 버그는 줄어듦)
- 투명한 설계 패턴: 설계를 공개했을 때, 시스템 공략이 불가능하다는 점을 보여줄 수 있음. 비밀성에 의존해서는 안됨. 예를들어 암호 시스템에서 암호화 알고리즘은 항상 공개되는 것이 원칙이다.
2. 노출 최소화 패턴 그룹
안전한 쪽을 선택하는 것
- 최소 권한 패턴: 작업에 필요한 최소한의 권한만 사용하낟., 공격자에게 권한들 적게줘서 활용할 수 있는 권한을 줄이게 함.
- 최소 정보 패턴: 작업에 필요한 개인정보는 최소한으로 수집해서 접근
- 안전이 기본 패턴: 별도의 설정 없이도 안전해야한다. -> 특별한 조치 없이도 안전해야된다는 것.(https 연결, 보안 설정 기본 동작, 등등..)
- 차단리스트보다 허용리스트 기반 패턴: 일단 다 차단하고 필요한 항목에 대해서만 허용하는 것. 차단리스트는 차단 리스트에 있는것만 차단되고 나머지가 허용될 수 있다.
- 예측 가능성 방지 패턴: 예측 가능한 모든 데이터는 추측을 통해 알아낼 수 있음.
- 안전한 실패 패턴: 문제 발생시 안전한 상태로 종료가 되어야함.
3. 강력한 집행 패턴 그룹
규칙을 철저하게 적용해서 코드의 동작을 보장하는 방법이다. 어떤 동작을 하지 않을 것이라 생각하고 코드를 작성하는 거싱 아닌 금지된 동작에 대해서 불가능하도록 설계를 하는 것이다.
- 완전한 중재 패턴: 모든 접근 경로를 보호하고, 예외 없이 동일한 접근 방법을 적용한다. 보호 자산에 대한 모든 접근을 일관되고 안전하게 검사하는 것이다. 여기서 보안 결정 구현 방법은 높은 수준의 규정 준수, 중간 수준, 낮은 수준으로 있다. 높은 수준의 규정 준수는 하나의 공통 루틴을 통해서만 리소스 접근이 허용, 중간 수준의 규정 준수는 여러 위치에서 리소스에 접근하지만 각각은 동일한 권한 부여 검사에 의해 보호된다. 낮은 수준의규정 준수는 여러 위치에서의 리소스에 접근하며, 일관성 없는권한 부여 검사에 의해 다양하 방법으로 보호된다.
- 최소 공통 메커니즘 패턴: 공유 메커니즘을 최소화해서 독립적인 프로세스들 사이의 격리를 유지한다. 만들때는 독리적인 프로세스나 다른 사용자와의 인터페이스 설계가 필요하다. 예를 들어서 데이타베이스를 보면 사용자별로 데이타베이스를 제공하면서 접근 범위를 지정할 수 있는지 고려해야한다.
4. 중복성 패턴 그룹
소프트웨어를 더 안전하게 만들기 위해 중복을 적용하는 방법을 보여줌
- 심층 방어 패턴: 독립적인 여러 보호 계층을 결합하여 전체 방어가 더욱 강력해지며, 시너지 효과로 인해 그 어떤 단일 계층보다 훨씬 더 효과적이다. 예를 들어 여러 단계의 문제점을 검출하는 샌드박스 구현이 있다.
- 권한 분리 패턴: 두 명의 당사자가 한 명의 당사자보다 더 신뢰할 만 하다. 권한을 분리해야 내부 공격 등에 대해서도 방지가 가능하다.
5. 신뢰와 책임 패턴 그룹
협력은 작동하게 만드는 접착제
- 신뢰에 대한 저항 패턴: 신뢰는 확고한 증거를 바탕으로 하는 명백한 선택이어야 한다. 당연한것도 확인하고 진행하여야 한다.
- 보안 책임 수용 패턴: 모든 소프트웨어 전문가는 보안을 책임져야하는 의무이며, SW에 대해서도 이런 태도의 반영이 필요하다.
6. 안티패턴 그룹
보안 관점에서 반드시 피해야하는 패턴
- 혼동된 대리인 패턴: 많은 소프트웨어 취약점의 핵심에 있는 근본적인 보안 문제, 버퍼 오버플로우나 부실한 입력 유효성 검사, 낮은 권한이랑 높은 권한을 두개 같이 주는 것 .. 이런게 있다.
- 신뢰의 역류 패턴: 낮은 신뢰도의 컴포넌트가 높은 신뢰도의 컴포넌트를 제어할 때 발생한다. 예를들어서 시스템 관리자가 개인컴퓨터로 기업의 시스템을 원격으로 관리한다던가..
- 서드파티 훅 패턴: 시스템 내부 컴포넌트의 훅이 서드파티에 과도한 접근을 제공하는 패턴이다. 예를 들어 사용빈도가 높은 AI 컴포넌트를 사용하고 직통 터널을 연결하면 이 컴포넌트를 통해 데이터가 빠져나갈 위험이 존재한다.
- 패치 불가능 컴포넌트 패턴: 활용성이 높은 컴포넌트의 취약점은 패치가 필요하지만 불가능한 경우이다. 바이너리만제공하거나 오래된 언어이거나 등등의 이유로..
보안 설계 원칙
보안 통합을 고려한 소프트웨어 설계의 기본 원칙
보안 설계 프로세스는 통합적, 보안 설계 리뷰는 분석적으로 봐야..
설계의 보안 통합 - 설계 가정의 명시화 및 범위 설정
- 설계 가정의 정의화: 암묵적인 가정으로 인한 보안 문제 발생가능. 빠뜨리기 쉬운 가정등을 안해서 생기는거나.
- 범위 정의의 원칙: 다루는 문제가 무엇인지를 확인하고 여러 범위들에 대해 명확히 해야한다.
- 의존성과 보안 관리의 필요성
설계의 보안 통합 - 보안 요구사항 설정
- CIA 중심의 보안 요구 사항 설정: 기밀성, 무결성, 가용성
- 보안 중요도에 따른 고려: 중요도 보여주고 상세히 설명해야함
- 보안 요구사항 수립 지침: 보안 요구 사항을 방법으로 제시하지 말고 최종 목표로 표현해야한다. 모든 이해 당사자의 요구사항을 고려하고 요구사항들이 상충되는 경우 적절한 균형이 필요하다. 특이한 요구사항이 있다면 동긷 ㅗ설명하고 달성 가능한 보안 목표를 설정해야한다.
설계에 보안 통합 - 위협 모델링
- 위협 모델링의 통합적 접근: 설계 프로세스에 윟벼 모델링을 내재화 해야한다. 설계의 장단점을 보여주면서 설계자가 올바른 선택을 할 수 있도록 해준다.
- 시스템의 범위 설정의 중요성: 신뢰경계와 공격 표면 관리가 필요하다.
- 필수 위협 모델의 활용: 구현 방식과 상관없이 이상적인 설계에 내재된 보안 위협을 모델링한 것이다.
- 타협이 필요할 경우의 전략: 나중에 보안 보호 기능을 추가하기 쉽도록 유연성을 염두에 두고 설계
완화의 구현
무제점에 어떻게 대처할 것인가?(위협 모델링)
1. 인터페이스 설계
- 내부적으로는 인터페이스 정의 및 컴포넌트의 보안 책임을 이해한다. 입력의 유효성 검사를 하고 신뢰할 수 없는 데이터로 취급되어야하는지를 문서화한다. 신뢰 경계가 있을 때는 경계를 통과하기 위한 인증과 권한 부여를 다루는 방법을 설명한다.
- 외부적으로는 외부 컴포넌트의 기존 설계 명세를 준수하도록한다. 정보가 없다면 가정을 문서화하고 불확실성을 보완하기 위한 방어적 전술을 고려한다.
- 안전한 인터페이스 설계: 동작방법을 명확히 기술한다. CIA 등의 내용을 포함해서..
2. 데이터 처리 설계
- 안전한 데이터 처리를 위해서 데이터 보호 목표의 큰 틀을 수립한다.
- 개인정보는 기본적으로 민감한 것으로 취급한다.
3. 개인정보보호와 소프트웨어 프로세스의 통합
- SW 개발 과정에서 개인정보보호를 고려한다.
- ㄱ인정보보호 정책을 소프트웨어 설계에 통합하기 위한 일반적인 기법이다.(보존기간 제한되면 삭제 보장 시스템 만들거나..)
- SW와 데이터 수명 주기를 관리한다.
4. 트레이드오프 처리 및 설계 단순성
- 트레이드 오프의 기본 원칙: 보안 완화 조치는 위험은 감소하지만 복잡성 증가로 버그가 발생할 수 있다.
- 최악의 시나리오를 예상해 대비가 필요하다.
- 보안 수준은 어떤 사이트인지 등등에 따라 차별화해서 적용해야한다.
- 설계는 단순해야한다.
보안 설계 리뷰
1. 수행 시기와 문서화 요건
- 언제할까? 집중하는 부분의 차이가 있으니 기능 리뷰 이후 시점을 권장한다. 설계 수정의 기회를 주기 위하여라면 설계 이전에 하는 것을 권장한다.
- 예비 보안 설계 리뷰를 고려해야한다.
- 설계자와 리뷰어의 역할을 분담한다.: 설계자는 보안의 책임자이고 리뷰어는 설계자를 지원한다.
- 문서화의 중요성과 문서화의 품질 요건: 설계 문서가 있어야 리뷰가 가능하다. 문서화가 잘 되어있어갸 좋은 설꼐 리뷰가 가능하다.
2. 프로세스
- 프로젝트에 대한 기본적인 이해를 얻기 위해 설계 및 지원 문서를 검토
- 설계에 대해 문의하고 기본적인 위협에 대해 명확하게 질문
- 집중적인 검토를 위해 설계에서 보안상 가장 중요한 부분을 식별
- 위험을 식별하고 완화 조치를 논의하기위해 설계자와 협력
- 발견사항과 권장사항에 대해 요약 보고서를 작성
- 최종 승인 전에 해결 여부를 확인하기 위해, 추후 설계 변경에 대한 후속 조치
설계 보안평가 - 4가지 질문
위협 모델리의 4가지 질문을 서례 기뷰의 지침으로 활용한다.
1. 우리가 다룬 문제는 무엇인가?
2. 무엇이 잘못될 수 있는가?
3. 문제점에 어떻게 대처할 것인가?
4. 우리가 제대로 작업을 했는가?
이후 심화적으로는 핵심 영역에 집중하고 개인정보보호관점에서 정책을 준수했는지 확인하거나 업데이트 리뷰를 하는 것 등이 있다.
설계 보안 평가 - 이견 관리
이견 관리란: 원만한 대인관계 소통이 성공적인 보안 설계 리뷰를 수행하는데 결정적으로 작용한다.
연구 사례로는.. 보안 설꼐 리뷰를 시간 낭비로 여기고 출시를 가로막는 장애물로 인식하는 개발팀이 이씅ㅁ. 여기서 창의적인 대안과 직접 소통을 해서 성공적 리뷰의 최종결과를 얻을 수 있음.