BULK INSERT가 위험한 것으로 간주되는 이유는 무엇입니까?

일반적인 사이버 보안 팀 (내가 처리 한 둘 이상의 조직)이 BULK INSERT응용 프로그램 및 데이터베이스 프로그래머에게 TSQL 등의 권한을 부여하지 못하는 이유를 알고 싶습니다 . 최종 결과가 다음과 같은 응용 프로그램과 다르지 않기 때문에 무언가를 놓치지 않으면 "디스크 남용 채우기"변명을 믿을 수 없습니다.

for (long i = 0; i < LONG_MAX; ++i)
    executeSQL("INSERT INTO table VALUES(...)");

및 INSERT기본 쓰기 권한을 가진 사람이 실행할 수있는 일반적인 DML 명령입니다.

응용 프로그램의 이점을 위해 BULK INSERT훨씬 효율적이고 빠르며 프로그래머가 SQL 외부에서 파일을 구문 분석 할 필요가 없습니다.

편집 : 나는 원래 정보 보안 사이트 에서이 질문을 한 이유-BULK INSERT를 사용하는 것에 반대하는 DBA가 아니라 문제를 강요하는 "정보 보증"(IA는 짧음-사이버 보안 담당자)입니다. 이 질문을 하루나 이틀 동안 찌르도록하겠습니다. 그러나 대량 작업이 실제로 제약 조건이나 트리거를 우회하는 경우 문제가 있음을 알 수 있습니다.

알려지지 않은 위험이있는 것처럼 근거없는 두려움이있을 수 있다고 생각하면, 누가 누가 정책을 만들 었는지 묻지 않고 정책이 왜 존재하는지 말하기는 어렵다고 생각합니다.

그러나, 나는 아마 함께 할 수있는 뭔가가 생각 될지 BULK INSERT/ SqlBulkCopy/ BCP /이 OPENROWSET(BULK ...)사람이 즉, 수행 할 수 :

1. 제약 조건을 비활성화하십시오 ( CHECK, DEFAULT그리고 FOREIGN KEY나는 믿습니다)
2. 비활성화 트리거 (장소에 감사 트리거가있는 경우,에 의해 통과를 아마도 바람직하지 않은 것으로 간주 될 것이다이 특정 문제에 대한 자세한 설명을 참조하시기 바랍니다 @DVKs 대답 )

다양한 옵션은 다음 설명서에 설명되어 있습니다.

• SqlBulkCopyOptions 열거 형
• 대량 삽입

@RDFozz가 지적한 테이블 잠금 문제는 언급되지 않았습니다 BULK INSERT. 누구나 TABLOCK / XLOCK을 테이블로 설정하거나로 설정할 TRANSACTION ISOLATION LEVEL수 SERIALIZABLE있습니다.

최신 정보

나는 이것을 좁히는 데 도움이 될 두 가지 추가 정보를 발견했다.

1. 비활성화 트리거, 비활성화 제약 및 세트 수 있다는 문제가 IDENTITY_INSERT ON있습니다 되지 볼 수있는 압도적 인 이유 ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS또는 (SQL 서버 2017로 시작) bulkadmin위협으로 서버 역할. 그 이유는 위에서 언급 한 세 가지 작업 중 하나를 수행하려면 ALTER TABLE해당 테이블 또는 테이블이 존재하는 스키마에 대한 사용 권한이 있어야하기 때문 입니다. 소유권 체인에는 DDL 수정 내용이 포함되지 않습니다. 따라서 사용자에게이없는 경우이 ALTER TABLE세 가지 작업을 수행 할 수있는 능력은 문제가되지 않습니다.

2. 어떻게 지금까지 논의, 무엇을 궁극적으로 수 있습니다되지 않은 보안 문제 것은 그 모두 와 액세스 외부 리소스, SQL 서버의 외부. Windows 로그인을 통해 SQL Server에 액세스 할 때 파일 시스템 액세스를 수행하기 위해 해당 Windows 계정이 (를 사용하여 보안 컨텍스트를 전환하더라도) 가장됩니다 . 즉, 읽기 권한이 부여 된 파일 만 읽을 수 있습니다. 아무 문제가 없습니다.BULK INSERTOPENROWSET(BULK...EXECUTE AS LOGIN='...'

   그러나 SQL Server 로그인을 통해 SQL Server에 액세스하면 SQL Server 서비스 계정의 컨텍스트에서 외부 액세스가 수행됩니다. 즉,이 권한이있는 사람은 읽을 수없는 파일과 액세스 할 수없는 폴더에서 파일을 읽을 수 있습니다.

   최소한 SQL Server가 SQL Server 전용 계정으로 실행되도록 설정된 경우 (기본 설정 방법) 해당 사용자는 "SQL Server"계정이 액세스 할 수있는 파일 만 읽을 수 있습니다. 이것은 제한된 문제이지만 여전히 SQL Server 로그 파일과 같은 파일을 읽을 수 있습니다 (그리고 다음 예제를 테스트했지만 작동합니다).

   SELECT tmp.[Col1]
   FROM   OPENROWSET(BULK
      N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                     SINGLE_NCLOB) tmp([Col1]);

   대부분의 사람들은 MSSQL \ Log 폴더에 액세스 할 수 없으므로 기존 보안 제한을 피할 수 있습니다.

   그리고 SQL Server가 Local System계정으로 실행 중이 면 문제의 범위 만 증가하고이 권한이있는 사용자는 광범위한 시스템 관련 파일을 읽을 수 있다고 생각합니다.

   또한 대량 가져 오기를 수행하는 다른 방법 ( BCP 및 기타) SqlBulkCopy이 bulkadmin권한 / 역할을 필요로하지 않는 이유 일 수 있습니다. 이러한 방법 은 SQL Server 외부에서 시작되며 파일 시스템 권한을 자체적으로 처리합니다. 이 경우 SQL Server는 파일을 읽거나 SQL Server 외부에 도달하지 않으며 외부 프로세스에서 읽은 파일에서 가져올 데이터 만 수신합니다.

가능한 의미는 다음과 같습니다.

응용 프로그램의 이점을 위해 BULK INSERT는 훨씬 더 효율적이고 빠릅니다.

알았어 ...

프로그래머는 SQL 외부에서 파일을 구문 분석 할 필요가 없습니다.

우와 넬리. 여기서 멈춰 보자. T-SQL은 일반적으로 구문 분석에 가장 적합한 언어가 아닙니다. DB에 내용을 삽입하기 전에 구문 분석을 수행하는 것이 가장 좋습니다. 이를 수행하는 한 가지 방법은 TVP (Table-Valued Parameters)를 사용하는 것입니다. 사전 분석 및 유효성 검사 주제와 해당 데이터의 효율적인 대량 가져 오기를 다루는 다른 질문 (여기서는 DBA.StackExchange)에 대한 내 대답을 참조하십시오.

T-SQL : 사용자 정의 구문 분석 숫자 데이터, 조회 값이있는 CSV-> 테이블 파이프 라인

이것은 이전의 답변 ( "... disable triggers ") 에서 암시 되었지만, 비즈니스 관점에서 비활성화가 바람직 하지 않은 이유를 설명하지는 않습니다 .

많은 비즈니스에서 메인 테이블의 트리거는 다음과 같은 용도로 사용됩니다.

1. 무결성 제약 조건의 유효성 검사

2. 더 중요한 것은 데이터를 감사하는 것, 특히 해당 감사 테이블에 데이터를 삽입하는 것 (또는 기본 테이블의 감사 필드를 업데이트하는 것)입니다.

전자의 문제점이 무엇인지는 분명하다 (응용 프로그램은 다운 스트림 처리에 부정적인 영향을주는 나쁜 데이터를 삽입 할 수 있음). 후자의 경우 트리거가 비활성화되면 감사 정보가 없으므로 감사 관점에서 두 가지 문제가 발생합니다.

• 우선, 그룹으로서의 감사는 더 이상 데이터 변경을 감사 할 수 없으므로 기본 감사 기능을 내부 감사로 수행 할 수 없습니다.

• 둘째, 감사 기록이 부족하면 회사가 관리하는 감사 요구 사항 (예 : SAS 70)이 위반 될 수 있습니다. 이로 인해 회사는 계약을 위반할 책임이 있습니다.

또 다른 가능성은 BULK INSERT작업 실행의 영향입니다 .

일반적으로 이러한 종류의 작업은 가능하면 업무 시간 외로 실행되어 정상적인 활동을 방해하지 않습니다. 대량 삽입은 몇 시간 동안 테이블을 잠 가서 다른 삽입 (선택, 업데이트 또는 삭제)을 방지 할 수 있습니다.

또는 보안 측면에서 DoS 공격과 매우 유사한 결과를 생성 할 수 있습니다.

물론, 거래와 간단한 INSERT진술 로 우연히 또는 고의적으로이를 수행 할 수 있습니다 . 그러나 대량 삽입 프로세스 를 의도 한대로 사용 하면이 효과가 발생할 수 있습니다.

일반적으로 DBA는 백업 및 기타 예약 된 작업을 모두 완료해야하므로 근무 외 시간 활동을 구성하는 데 관여 할 것으로 예상됩니다. 사람들이 이러한 활동을 충분히 고려하지 않고 이런 종류의 일정을 예약했다면 백업이 실패하는 것을 볼 수 있습니다. 여러 가지 이유로 문제가 될 수 있습니다.

그 이유 중 하나는 작업 기록을 명확하게하는 데 있습니다. 모든 작업이 로그 파일의 한 항목에 해당하는 경우 추가 참조없이 문제를 일으킨 항목을 보는 것이 매우 간단합니다. 로그 파일에 external.file없이 "INSERT FROM external.file"이 표시되면 더 이상 아무것도 말할 수 없습니다.

물론 로깅의 작동 방식을 수정할 수는 있지만 시작점으로 모든 작업을 로깅 내에서 원 자성으로 만드는 것이 끔찍한 아이디어는 아닙니다.