설계상 안전
Secure by design |
| 시리즈의 일부 |
| 정보 보안 |
|---|
 |
| 관련 보안 카테고리 |
| 위협 |
|
| 방어. |
소프트웨어 엔지니어링에서 설계상 보안이란 소프트웨어 제품 및 기능이 근본적으로 안전하도록 설계되었음을 의미합니다.
대체 보안 전략, 전술 및 패턴은 소프트웨어 설계의 시작 부분에서 고려되며 아키텍처에 의해 최선의 보안 전략, 전술 및 패턴이 선택되고 적용되며 [1]개발자의 지침으로 사용됩니다.또한 보안에 이로운 효과가 있는 전략적 설계 패턴을 사용하는 것이 좋지만, 이러한 설계 패턴은 원래 보안을 [2]염두에 두고 설계되지 않았습니다.
Secure by Design은 소프트웨어 시스템의 보안과 프라이버시를 확보하기 위한 주류 개발 접근법이 되고 있습니다.이 접근법에서는 모든 계층에서 보안을 고려하고 시스템에 내장하며 견고한 아키텍처 설계부터 시작합니다.보안 아키텍처 설계 결정은 특정 품질 문제를 달성하기 위해 재사용 가능한 기술로 정의된 잘 알려진 보안 전략, 전술 및 패턴을 기반으로 합니다.보안 전술/패턴에서는 시스템이 공격을 [3]받고 있는 경우에도 필요한 인증, 인가, 기밀성, 데이터 무결성, 프라이버시, 어카운터빌리티, 가용성, 안전성 및 거부하지 않는 요건을 적용하기 위한 솔루션을 제공합니다.소프트웨어 시스템의 보안을 확보하기 위해서는 견고한 보안 아키텍처를 설계하는 것이 중요할 뿐만 아니라 보안 지속성을 유지하기 위해 갱신된 보안 전략, 전술 및 패턴을 소프트웨어 개발에 매핑하는 것도 필요합니다.
공격을 예상하다
소프트웨어에 대한 악의적인 공격이 발생하는 것으로 가정하고 영향을 최소화하기 위해 주의를 기울여야 합니다.잘못된 사용자 입력과 [4]함께 보안 취약성이 예상됩니다.이와 밀접하게 관련되어 있는 것은 도메인 기반 설계나 클라우드 네이티브와 같은 "우수한" 소프트웨어 설계를 사용하여 보안상의 취약성에 영향을 미치는 실수를 줄여 보안을 강화하는 방법입니다. 비록 사용된 설계 원칙이 원래 보안 목적으로 구상된 것은 아니지만 말입니다.
무명화를 통한 보안 회피
일반적으로 잘 작동하는 디자인은 비밀에 의존하지 않습니다.기밀성은 위협 집단의 하위 집합을 제거하여 공격자의 수를 줄이는 경우가 많습니다.공격자의 복잡성이 증가하면 공격자가 대상을 손상시키려는 노력이 증가하면 공격자가 이를 저지할 수 있다는 논리다.이 기술은 내재된 위험을 줄이는 것을 의미하지만, 시간이 지남에 따라 적용되는 위협 행위자 및 기법의 사실상 무한한 집합은 대부분의 비밀 유지 방법을 실패하게 만듭니다.적절한 보안은 필수사항은 아니지만 일반적으로 모든 사람이 설계를 알고 이해할 수 있도록 허용된다는 것을 의미합니다. 왜냐하면 설계가 안전하기 때문입니다.이것은 많은 사람들이 컴퓨터 코드를 보고 있다는 장점이 있는데, 이것은 결함이 더 빨리 발견될 확률을 높입니다(리니누스의 법칙 참조).단점은 공격자가 코드를 얻을 수도 있기 때문에 악용할 취약성을 쉽게 찾을 수 있다는 것입니다.그러나 일반적으로 개방된 컴퓨터 코드의 장점이 단점보다 더 크다고 믿는다.
가장 적은 권한
또, 모든 것이 가능한 한 최소한의 특권으로 동작하는 것이 중요합니다(최소 특권의 원칙 참조).예를 들어 관리 사용자("root" 또는 "admin")로 실행되는 웹 서버는 파일 및 사용자를 제거할 수 있는 권한을 가질 수 있습니다.따라서 이러한 프로그램의 결함은 시스템 전체를 위험에 빠뜨릴 수 있습니다.단, 격리된 환경 내에서 실행되며 필요한 네트워크 및 파일 시스템 기능에 대한 권한만 가진 웹 서버는 그 주변의 보안에 결함이 없는 한 해당 서버에서 실행되는 시스템을 손상시킬 수 없습니다.
방법론
시큐어 설계는 개발 라이프 사이클의 모든 시점에서 고려되어야 합니다(어느 개발 방법을 선택하든).
사전에 구축된 Secure By Design 개발 방법론(Microsoft 보안 개발 라이프 사이클 등)이 있습니다.
Microsoft 보안 개발 라이프 사이클
마이크로소프트는 고전적인 나선형 모델에 기초한 방법론과 지침을 발표했다.
표준 및 법령
「시큐어」의 정의를 제어하고, 시큐어 시스템의 테스트와 통합을 위한 구체적인 순서를 제공함으로써, 시큐어 설계를 보조하기 위한 표준과 법률이 있습니다.
Secure By Design 원칙을 다루거나 다루는 표준의 몇 가지 예는 다음과 같습니다.
- ETSI TS 103 645는 영국 정부의 "소비자 스마트 제품 사이버 보안을 규제하기 위한 제안"에 포함되어 있습니다.
- ISO/IEC 27000 시리즈는, 시큐어 설계의 다양한 측면을 커버합니다.
서버/클라이언트 아키텍처
서버/클라이언트 아키텍처에서는 상대편 프로그램이 인증된 클라이언트가 아닌 경우도 있고 클라이언트의 서버가 인증된 서버가 아닌 경우도 있습니다.이러한 경우에도 중간자 공격은 통신을 손상시킬 수 있습니다.
대부분의 경우 클라이언트/서버 시스템의 보안을 해제하는 가장 쉬운 방법은 보안 메커니즘으로 직진하는 것이 아니라 보안 메커니즘을 우회하는 것입니다.중간 공격에 있는 남자는 사용자를 가장하기 위해 세부 정보를 수집하기 위해 사용할 수 있기 때문에 간단한 예입니다.따라서 잠재적인 공격자로부터 수집된 정보가 접근을 허용하지 않도록 설계 시 암호화, 해시 및 기타 보안 메커니즘을 고려하는 것이 중요합니다.
클라이언트 서버 보안 설계의 다른 중요한 기능은 좋은 코딩 관행입니다.예를 들어 클라이언트 및 브로커와 같은 알려진 소프트웨어 설계 구조를 따르면 견고한 기반을 갖춘 잘 구축된 구조를 설계하는 데 도움이 됩니다.또, 장래에 소프트웨어를 변경하는 경우는, 클라이언트와 서버를 분리하는 논리적인 토대를 따르는 것이 더욱 중요합니다.프로그래머가 들어와 프로그램의 역동성을 명확하게 이해하지 못하면 보안 결함을 추가할 수 있는 내용을 추가하거나 변경할 수 있기 때문이다.최상의 설계라 하더라도 이는 항상 가능한 일이지만 설계의 표준화가 개선될수록 발생할 가능성이 낮아집니다.
「 」를 참조해 주세요.
레퍼런스
- ^ Santos, Joanna C. S.; Tarrit, Katy; Mirakhorli, Mehdi (2017). "A Catalog of Security Architecture Weaknesses". 2017 IEEE International Conference on Software Architecture (ICSA): 220–223. doi:10.1109/ICSAW.2017.25. ISBN 978-1-5090-4793-2. S2CID 19534342.
- ^ Dan Bergh Johnsson; Daniel Deogun; Daniel Sawano (2019). Secure By Design. Manning Publications. ISBN 9781617294358.
- ^ Hafiz, Munawar; Adamczyk, Paul; Johnson, Ralph E. (October 2012). "Growing a pattern language (for security)". Onward! 2012: Proceedings of the ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software: 139–158. doi:10.1145/2384592.2384607. ISBN 9781450315623. S2CID 17206801.
- ^ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (October 2009). "Secure Design Patterns". doi:10.1184/R1/6583640.v1.
{{cite journal}}:Cite 저널 요구 사항journal=(도움말) - ^ "ETSI TS 103 645" (PDF).
- ^ "Policy paper: Proposals for regulating consumer smart product cyber security - call for views".
