2017-03-08 10 views
0

그래서 코드 자체와 효율성 및 실용성에 관한 내용이 적습니다. 이전 직장에서는 여러 데이터베이스가있었습니다. 공개 수단을 통해 액세스 할 수있는 액세스 권한과 개인적으로 만 액세스 할 수있는 액세스 권한 공개 데이터베이스는 기본적으로 사적인 사람이 한 모든 것을 보여줄 수 있었고 거의 2 분마다 최신 상태로 유지되었습니다. 공용 데이터베이스가 일부 SQL 주입 또는 데이터베이스를 파괴하는 악의적 인 것으로 파괴되면 생산을 해치지 않고 즉시 복원 할 수 있다는 아이디어가있었습니다.SQL 이중 데이터베이스 보안

그러나 꽤 작은 규모의 작업으로 한 번에 약 100 명의 사람들이 데이터베이스에 액세스했는데 아무런 문제가 발생하지 않으면 누군가가 직접 수동으로 데이터베이스를 복원하여 문제를 해결해야한다는 것을 확신합니다. .

제 질문은 올바른 방법입니까? 이런 종류의 전술은 언제까지 믿을 수 없을 정도로 비효율적이게됩니까? 하루에 수십 만 건의 쿼리를 처리하는 중이라면 이것이 유지가 어려울까요?

통찰력을 가져 주셔서 감사합니다.

+1

"이 작업을 수행하는 올바른 방법입니까?" - 그렇지 않을 수도 있습니다. 데이터베이스를 직접 노출하지 마십시오. 그것 위에 허가 된 API를 두십시오; 최소한의 읽기 전용보기 또한 OLTP와 OLAP 문제를 혼용하지 마십시오. –

+0

* 공개 데이터베이스 *는 항상 나쁜 생각입니다. 하지만 : 공용 DB가 SQL Injection에 영향을받는다면, 개인용 데이터베이스도 마찬가지입니다. 왜냐하면 데이터가 거기에 있어야하기 때문입니다. 그렇지 않습니다. 또한 ** 백업 **으로 완화 할 수있는 데이터 삭제 대신 데이터 유출에 대해 걱정해야합니다. 그래서 대부분의 노력은 당신의 ** 코드 안전 **과 당신의 데이터베이스 ** 공개 **로 만들어야합니다. –

답변

0

첫 번째 방어선은 데이터베이스에 액세스 한 소프트웨어 여야합니다. SPs를 사용하는 것처럼 SQL 주입을 방지하기 위해 여러 가지 방법이 있지만 쿼리 대신 매개 변수를 보내야합니다. 시스템 사용자가 개인 데이터베이스를 가진 데이터 (이 포럼과 같은)를 제공하는 것이 데이터베이스 복사본을 갖는 것 (2 분마다 동기화한다는 것, 공용의 변경 사항이 개인용 데이터베이스를 변경 함)보다 낫지 않습니다. 다른 간격으로 다른 데이터 사본을 가질 수 있으며 언제든지 상황이 좋을 때 언제든지 롤백 할 수 있습니다.

저는 은행에서 일하면서 테이프에 복사본을 만들었습니다! SQL 인젝션보다 더 큰 일이 생길 경우를 대비하여 쓰기/읽기 전용 테이프입니다!