보안에 관한 대부분의 문서에서는 메커니즘과 구현에 대해 운동하기 전에 보안 정책을 정의하는 것이 중요하다고 말합니다. 논리적 인 것처럼 보이지만 실제로 보안 정책을 정의하는 것이 무엇을 의미하는지는 분명하지 않습니다.시스템에 대한 보안 정책 정의
여기 사람이 보안 정책을 정의하는 어떤 경험이 있었나요, 그렇다면 :
1) 이러한 정의의 결과는 무엇입니까? 그러한 정책의 형태는 말하자면 분산 시스템이란 시스템의 보안 요구 사항에 대한 일련의 진술을 포함하는 문서 (허용되는 것과 허용되지 않는 것)입니다.
2) 정책이 기계 가독 형식 (해당되는 경우)을 사용할 수 있습니까? 그렇다면 어떻게 사용할 수 있습니까?
3) 이러한 정책을 어떻게 유지합니까? 시스템의 정책은 설명서의 나머지 모든 문서와 마찬가지로 유지 관리됩니까?
4) 정책 문서를 코드로 참조해야합니까? 당신이 보안 정책을 설계해야하는 경우
브라이언
, 왜 사용자 및 사용 권한에 대해 생각하지?
그래서 API를 가지고 있다고 가정 해 보겠습니다. 원하는대로 사용자를 분류하고 사용자가 필요로하는 최소 권한을 고려하십시오. 따라서 누군가가 데이터베이스에서 문서를 읽는 것만으로 API 자체가 사용자가 다른 작업을 수행하게하지는 않습니다.
웹 JSON API를 상상해보십시오. 사용자가 버튼을 클릭하고 JS가 요청을 처리하여 전송합니다. 일반적으로 정상적으로 작동하지만 누군가가 요청을 변조하면 서버는 사용자가 할 수있는 몇 가지 작업 만 화이트리스트에 포함하기 때문에 오류 코드를 반환합니다.
그래서 모든 것이 사용자와 권한으로 귀결됩니다.
이것은 매우 좁은 보안 환경에 중점을두고 있습니다. 다른 환경에서는 설정이 매우 다릅니다. 예를 들어, 통계 정보 공개에 대한 요구 사항을 고려하십시오. 또는 허용 된 작업이 현재 데이터 및 조건에 의존하는 시스템. – Novelocrat
정책을 개발해야하는 가장 일반적인 상황으로 생각되는 부분에 의도적으로 단순화되었습니다.IMHO 대부분의 보안 정책은 특정 데이터에 액세스해야하거나 그렇지 않아야하는 최종 사용자에 대한 것입니다. 게다가이 문제는 완전히 해결하기가 어렵습니다 (아마도 당신이 나보다 더 잘 이해할 수 있기 때문에 시도해 주셨으면합니다). –
''또는 허용 된 동작이 현재 데이터 및 조건에 의존하는 시스템 "- 사용자 및 허용 된 권한"접근 방식이 효과가있는 것처럼 보입니다. –
표준 보안 정책 중 하나를 선택하여 작업해야합니다. 가장 보편적 인 것은 PCI 준수 (지불 카드 산업)입니다. 그것은 아주 잘 생각하고 일반적으로 좋은 몇 부드러운 반점을 제외하고. Microsoft Active Directory 정의 또는 일련의 Linux iptables 규칙을 제외하고는 기계 판독 가능 정책에 대해 들어 본 적이 없습니다.
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
편집 : 또한
체크 아웃 SE 리눅스 정책 :
오픈 웹 애플리케이션 보안 프로젝트 OWASP은 언어 무신론자 프로젝트가 보안에 대해 교육하고 제공하는 것입니다 소프트웨어를 테스트하고 지원하는 도구. 웹 중심적이지만 많은 핵심 아이디어가 널리 적용됩니다. 이 웹 사이트는 소프트웨어 엔지니어와 관리 모두를 대상으로합니다.
사람들은 "보안 정책"에 대해 이야기 할 때 두 가지 유형의 보안 정책을 언급 할 수 있습니다.
그 중 하나는 일반적으로 관리로 정의되는 상위 수준의 수준입니다. 이 보안 정책의 주요 독자는 사람입니다. 경영 목표에 대한 목표, 상황, 기대치 및 보안 요구 사항을 정의하는 문서입니다.이 정책에서 사용되는 언어는 모호 할 수 있지만 적용하는 맥락에서 보안의 기본 "법칙"입니다. 관련된 모든 사람이 그러한 방침을 따라야합니다.
1) 정책의 결과는 관리자가 명확하게 정의한 보안 요구 사항입니다. 이 정책을 통해 관련된 모든 사람이 경영진의 기대를 이해하고 필요할 때 보안 관련 판단을 내릴 수 있습니다.
2) 이러한 보안 정책의 주요 독자는 사람이며 일반적으로 매우 일반적이므로 컴퓨터에서 읽을 수있는 형식이 아닐 수 있습니다. 그러나 보안 지침, 절차 및 설명서라는 정책에 대한 기본 문서가 두 개있을 수 있습니다. 그것들은 보안이 실제로 어떻게 구현되어야하는지에 대한 상세한 단계의 순서에 있습니다. 예를 들어, 보안 정책에 정의 된 요구 사항은 다른 OS에 대한 강화 된 매뉴얼로 구현되어 관리자와 엔지니어가 관리자의 생각을 너무 많이 해석하지 않고도 효율적으로 강화 작업을 수행 할 수 있습니다. 그런 다음 강화 작업 설명서는 강화 작업을 자동화하는 일련의 기계 판독 가능 구성 (예 : 최소 암호 길이, 계정 잠금 전 최대 실패 로그인 횟수 등)으로 바뀔 수 있습니다.
3) 문서는 관련자 모두가 이용할 수 있도록 만들어야하며 관리가 정기적으로 검토해야합니다.
4) 실제로 그러한 참조를하기가 어려울 수 있습니다. 보안 정책은 수시로 업데이트 될 수 있으며, 정책 변경이 일부 매개 변수에만 영향을 줄 경우 프로그램을 다시 컴파일하지 않으려 고합니다. 그러나 디자인 sepc와 같은 개발 문서의 정책을 참조하는 것이 좋습니다.
"보안 정책"의 또 다른 유형은 보안 프로그램 인 매개 변수 집합을 나타낼 수 있습니다. 일부 보안 프로그램은 실제로 "정책"이라는 단어를 사용하여 구성을보다 체계적으로 구성하고 구조화하는 것을 선호합니다. 그러나 어쨌든, 이러한 "보안 정책"은 실제로 보안 프로그램에 대한 가치 및/또는 지침입니다. 예를 들어 Windows에는 감사 로깅, 사용자 권한 등을 구성 할 수있는 자체 "보안 정책"집합이 있습니다.이 유형의 "보안 정책"(프로그램 매개 변수)은 실제로 "보안 정책"의 첫 번째 유형을 기반으로 정의됩니다. (경영진의 요구 사항).
나는 이것에 너무 많이 쓰고 있습니다. 희망이 도움이됩니다.
프로그래밍에 관한 것 같지 않습니다. 서버 오류로 마이그레이션하기 위해 투표하는 기업 수준의 보안에 관한 것 같습니다. –
@ David : 나는 강력하게 동의하지 않습니다. 보안 함의가있는 시스템을 설계 할 때 구현되는 메커니즘은 잠재적 인 정책 범위를 지원해야합니다. – Novelocrat
@Novelocrat : 확실히, 메커니즘을 프로그래밍하는 것은 여기에 주제에 관한 것입니다. 그러나 이것은 여러 가지 방법으로 구현되는 일종의 규칙을 수립하는 것과 관련이 있습니다. 프로그래밍 관련 문제가있을 수 있으며 SO에 대한 주제가 아닙니다. –