응용 프로그램의 각 사용자에 대해 별도의 데이터베이스 계정을 사용하는 것이 좋은 방법입니까?

내가 사용했던 응용 프로그램은 서버 기반이며 많은 사용자에 대해 하나의 데이터베이스 계정을 사용하며 응용 프로그램 코드는 사용자가 수행 할 수있는 작업 또는 단일 사용자를 제어합니다.

개인마다 고유 한 데이터베이스 계정이 필요한 성공적인 복잡한 비즈니스 응용 프로그램이 있습니까? 데이터베이스 서버는 각 사용자가 허용하고 허용하지 않아야 할 사항에 대한 정책 규칙을 시행하기 위해 의존하고 있습니까?

여러 사람이 한 데이터베이스의 정보에 기여하고 다른 사람이 저장 한 정보 (예 : 고객 레코드에 모두 액세스해야하는 조직의 동료)에 액세스 할 수있는 응용 프로그램을 생각하고 있습니다.

이 유형의 설정에 대한 이름도 있습니까?

데이터 수준에서 실제로 엄격한 제어가 필요한 경우. 예를 들어 광범위한 감사. 여러 사용자가 동일한 계정을 공유하는 경우 감사가 그리 좋지 않습니다. 데이터 데이터베이스에 직접 액세스해야하는 일부 사용자가있는 경우

보안이 엄격한 경우 일반적으로 데이터베이스를 직접 노출하지도 않습니다. 서비스가 있으며 클라이언트가 서비스에서 데이터를 가져와야합니다.

웹 응용 프로그램에서 데이터베이스 (예 : 포트 1433)는 일반적으로 직접 노출되지 않으므로 보안 수준이 높아집니다. 웹 응용 프로그램이 데이터베이스에 직접 액세스하더라도 사용자는 여전히 데이터베이스에 직접 액세스 할 수 없습니다 .

로그인 및 비밀번호가 클라이언트 애플리케이션에있는 경우 해킹 될 수 있습니다. 도메인 인 경우 통합 보안을 사용할 수 있습니다.

데이터베이스에서는 꽤 세밀한 제어가 가능합니다. 그러나 행 수준 제어는 약간의 작업입니다. 데이터베이스는 비즈니스 규칙에 적합한 도구가 아닙니다. 비즈니스 규칙 및 자세한 보안은 일반적으로 응용 프로그램 수준에서 시행됩니다.

관리자가 사용하는 일부 저장 프로 시저가 있고 혼합 된 관리자를 추적하려는 혼합 모드를 사용할 수 있습니다. 또한 보고서를 직접 생성하는 사용자에게 읽기 권한 만 부여 할 수 있습니다.

여기서 문제는 데이터베이스 액세스가 추상화로 관리된다는 것입니다. 사용자는 스스로 연결하는 대신 본질적으로 일부 일반화 된 응용 프로그램 역할의 ID를 갖습니다. 개별 연결에 대한 가시성을 잃을뿐만 아니라 모든 개별 사용자에 대해 서로 다른 유형의 액세스를 정의 할 때 세분성을 잃게됩니다.

이 방법을 사용하는 주된 이유는 단순성입니다. 많은 응용 프로그램은 응용 프로그램 사용자가 데이터베이스에 대해 알지 못하도록 설계되었습니다. 특히 애플리케이션이 자체 내부 보안을 관리하는 경우에는 필요하지 않습니다. 대부분의 개별 사용자는 데이터베이스에 직접 연결하지 않으므로 명시적인 로그인을 정의 할 필요가 없습니다.

데이터베이스에 보안을 관리 할 수있는 유일한 시점은 데이터베이스에 직접 연결할 사용자가있는 경우입니다. 이것은 그들이 당신의 응용 프로그램을 돌아 다니고 더 이상 자체적으로 보안을 시행 할 수 없다는 것을 의미합니다. 여기서 장점은 보안 정의에 대해보다 세분화 될 수 있다는 것입니다. 단점은 사용자 및 권한을 관리하기위한 오버 헤드가 높다는 것입니다.

이런 종류의 액세스가 필요하다고 생각되면 역할 기반 액세스 제어 를 사용하려고 합니다 . 데이터베이스 내에서 어떤 종류의 권한이 필요한지에 따라 역할을 정의한 다음 해당 역할에 따라 개별 사용자를 그룹화해야합니다. 이를 통해 보안 모델에 대한 감사 및 제어 기능이 향상되어 직접 액세스를 관리 할 때 제어 범위를 빠르게 벗어날 수 있습니다.

이에 대한 하이브리드 접근법이 있습니다. 데이터베이스에서 보안을 부분적으로 관리하려는 경우 각각 역할별로 정의 된 여러 애플리케이션 사용자를 작성하고 해당 역할에 따라 해당 사용자에게 명시 적으로 액세스 권한을 부여 할 수 있습니다. 즉, 일부 보안 모델에 데이터베이스 엔진을 활용할 수 있지만 여전히 응용 프로그램 내에서 일부 관리를 수행해야합니다. 응용 프로그램 사용자 모델의 복잡성을 증가 시키지만 사용중인 다른 로그인에 대해 세밀한 정보를 제공합니다.

최대한 빠른 시일 내에 보안을 강화해야합니다. 이와 관련하여 역할이 도움이됩니다. 한 번에 여러 테이블에 액세스 할 수있게하는 것은 악몽이 아닙니다.

모든 사람을위한 단일 계정은 여기와 다른 곳에서 훌륭한 질문의 원천입니다. "기록 x가 삭제되었습니다. 누가 어떻게했는지 알 수 있습니까?" 대답은 개별 계정이나 감사 없이는 할 수 없다는 것 입니다.

"감사"란 모든 사람이 계정을 보유하고 있지만 모든 사람이 계정을 보유하고 있다고해서 이것이 진정한 보안을 의미하는 것은 아닙니다. 예를 들어 HR 테이블의 레코드가 삭제되면 HR 테이블에 액세스 할 수있는 누군가가 그렇게했음을 알 수 있습니다. x 명입니다.

시스템에 조치 X를 수행 한 개별 레벨까지 추적 할 수있는 조치를 로그하는 트리거가 필요합니다 (자동화 할 수있는 Oracle과 같은 RDBMS가없는 경우).

어쨌든 가능한 빨리 보안을 최대한 세분화해야합니다. "알아야 할"사람 만 테이블에 액세스 할 수 있도록하십시오. 그리고 항상 테이블 작업에 대한 타임 스탬프를 포함하십시오. 사람들은 종종 다른 사람들에게 자신의 ID를 제공합니다. "Jimmy, 당신은 17:49에 사무실에서 유일한 사람이었습니다."라고 말할 수 있다면 ... 당신의 화살통에있는 다른 화살.

어쩌면 RDBMS를 우리에게 주었을 때 상황에 대해 더 구체적 / 관련 조언을 얻을 수 있습니까?

그렇습니다. 강력한 단일 사용자로 응용 프로그램에서 데이터베이스에 연결하는 것은 최소 권한 원칙을 위반합니다 . 이것이 대부분의 SQL 인젝션 공격의 근본 원인입니다.

이것은 대개 무지, 단순성을 위해 또는 때로는 성능으로 인해 수행됩니다.

데이터베이스는 종종 오랜 시간 동안 여러 애플리케이션에서 동시에 사용됩니다. 여러 응용 프로그램 대신 데이터베이스에서 액세스 제어를 중앙 집중화하여 리소스를 절약 할 수 있습니다.

행 보안, 열 보안 및 가장 / 프록시 인증 (실제 db 사용자 + 연결 풀링 지원)을 지원하는 DB 서버를 선택하려고합니다.

또한 숙련되지 않은 플러그인 작성자로 인한 SQL 삽입을 피하기 어려운 Wordpress와 같은 "플러그인"기반 응용 프로그램의 경우 더 안전합니다. 각 플러그인은 전체 애플리케이션 대신 DB 로그인을 얻습니다.