개념 스키마가 게시 된 보안 위험은 어느 정도입니까?

연구를 위해 정부 기관의 정보 시스템에서 개념적 스키마를 요청했습니다. 보안 위험으로 인해 요청이 거부되었습니다.

나는 광범위한 데이터베이스 경험이 없기 때문에 그 주장을 확인할 수 없습니다. 스키마를 공개하는 것이 실제로 그렇게 큰 보안 위험입니까? 나는 그것들이 꽤 추상적이며 하드웨어 및 소프트웨어 구현과 이혼했다는 것을 의미합니다. 공격자가 개념적 스키마를 악용 할 수있는 방법에 대한 설명을 부탁드립니다. 감사.

gbn (+1)과 동의했지만 다른 두 가지 가능성이 있다고 생각합니다.

1. 그들의 개념적 스키마는 실제 스키마와 많은 중복이있을 수 있습니다. 테이블 이름을 알면 SQL 인젝션 공격을 계획하는 데 유리한 출발점이됩니다.

2. 개념적 스키마가 문서화되어 있지 않을 가능성이 큽니다. 프로그래머가 자신의 데이터베이스를 설계 할 수있게 해주는 조직은 데이터베이스 설계 프로세스가 엄격하지 않아 초기 설계없이 실제 구현으로 바로 이동합니다. 그들은 이것을 인정하기를 원치 않거나 존재하지 않았던 개념적 문서를 다시 작성하는 데 어려움을 겪고 싶지 않을 수도 있습니다.

편집 : OP는 개념적 스키마를 요청하는 조직이 정부 기관이라고 언급했습니다. 이것은 내 마음에 또 다른 가능성을 추가합니다.

공무원들은 위험 감수에 대한 사랑으로 잘 알려져 있지 않기 때문에 정부 부서의 중간급 직원은 목숨을 잃고 정보를 공개하지 않을 가능성이 있습니다. .

여전히 # 2가 가장 가능성이 높다고 생각합니다.

지적 재산권 위험이라고 말하고 싶지만 말하고 싶지 않았습니다.

본인은 비밀 정보의 개념 스키마도 비밀로 유지해야한다는 데 전적으로 동의합니다.

정탐꾼이 어떻게 든 균열을 통해 미끄러 져 나오는 약간의 정보를 수집하더라도 이러한 정보를 맥락에 두는 데 여전히 문제가 남아 있습니다. 개념적 스키마는 컨텍스트를 제공합니다. 수집 된 tidbits의 형식과 내용은 데이터베이스에있는 데이터의 형식과 내용과 실질적으로 다를 수 있지만, 실질적인 스키마는 내용을 디코딩하는 훌륭한 지침을 제공합니다.

회사의 데이터 복구 작업에서 저는 항상 신뢰할 수있는 개념적 스키마를 금광으로 간주했습니다. 확실히,이 프로젝트에는 스파이 활동이 포함되지 않았습니다. 그러나 동일한 분석이 어떻게 이루어지는 지 쉽게 알 수 있습니다.

많은 공급 업체가 데이터베이스 스키마를 가슴에 가깝게 유지하려고합니다. 데이터 무결성이 부족하거나 데이터베이스 디자인이 열악한 것과 같이 더러운 작은 비밀을 지키는 것입니다. 다른 이유는 다음과 같습니다.

• 많은 소프트웨어 제품이 데이터베이스 스키마를 잘못 설계했습니다.

• 지원 워크로드를 발생시키지 않으려는 욕구.

• 고객이 시스템 통합 작업을위한 컨설팅 서비스를 구매하도록 강요합니다.

• 고객이 경쟁 업체 제품으로 마이그레이션하지 못하도록 출구 비용을 최대화하려는 요구.

불행히도 고객을 위해 일하고 있지는 않지만 데이터베이스 스키마를 노출하는 것이 보안 위험이 될 수있는 소프트웨어의 구조적 결함을 조사하는 데 논쟁을 할 수 있습니다.