카우치베이스 서버 5.5 에는 사용자가 수행한 모든 N1QL 작업을 기록하는 기능이 포함되어 있습니다. 이것은 Couchbase의 보다 일반적인 감사 기능이 5.0에 도입되었습니다. 감사는 Enterprise 에디션에서만 사용할 수 있습니다.
감사를 통해 시스템 관리자는 시스템에서 누가 어떤 데이터에 액세스하는지 추적할 수 있습니다. 이는 저장되는 데이터가 사용자에 대한 정보와 같이 어떤 식으로든 민감한 데이터일 때 중요합니다. Couchbase Server 5.5는 N1QL 문 감사를 지원하며, 관리자가 실제로 어떤 유형의 문(SELECT? INSERT?)을 감사해야 하는지 지정할 수 있습니다.
Couchbase Server 5.5에서 지원하지 않는 기능을 이해하는 것이 중요합니다. 특히 레코드 수준 감사를 허용하지 않습니다. UPDATE 문이 실행되어 5개의 레코드를 수정하는 경우, 감사 레코드에는 전달된 모든 매개 변수를 포함하여 실행된 전체 문이 포함되며 5개의 레코드가 업데이트되었다고 표시됩니다. 어떤 특정 레코드가 업데이트되었는지 또는 작업 전과 후의 값은 알려주지 않습니다. 기본적으로 N1QL 감사는 레코드가 아닌 문을 감사합니다.
감사를 구성하려면 Couchbase 관리자 콘솔에 로그인합니다. 보안 탭(측면)과 감사 탭(화면 상단에 있음)으로 이동합니다. 이제 다음과 같은 화면이 표시됩니다:
이 탭에서는 일반적인 감사를 구성할 수 있습니다. 상단의 확인란은 감사를 수행할지 여부를 나타냅니다. "대상 로그 디렉터리"에는 감사 로그 레코드를 저장할 위치가 표시됩니다. 레코드는 대상 로그 디렉터리의 "audit.log"라는 파일에 나타납니다. 다음 텍스트 상자 세트는 크기와 시간 간격에 따라 로그 순환을 제어합니다.
다음은 다양한 유형의 이벤트에 대한 세 가지 드롭다운으로, 어떤 종류의 활동을 기록할지 세밀하게 제어할 수 있습니다. 일반적으로 꼭 필요한 것만 감사하세요. 감사의 실제 처리량 비용은 감사 대상과 감사 대상 명세서의 유형에 따라 달라집니다. 감사로 인한 처리량 손실 10%는 합리적인 즉석 추정치이지만, 새 시스템을 배포하기 전에 반드시 실제 효과를 테스트해야 합니다.
마지막으로 '이 사용자의 이벤트 무시' 상자에서 사용자를 화이트리스트에 추가할 수 있습니다. 이러한 사용자는 완전히 신뢰할 수 있는 사용자이므로 작업을 기록할 필요가 없습니다. 예를 들어 새 데이터를 삽입하는 자동화된 스크립트가 있을 수 있습니다. 이 스크립트를 전적으로 신뢰합니다. 화이트리스트 사용자를 만들고 스크립트에서 해당 사용자의 자격 증명을 사용하도록 하면 감사 레코드가 너무 많이 생성되는 것을 방지하는 데 유용할 수 있습니다.
'N1QL 이벤트' 드롭다운을 토글하여 N1QL에 사용할 수 있는 이벤트 유형을 확인합니다.
두 가지 일반적인 유형이 있습니다. 첫 번째는 N1QL 문 유형에 해당하는 이벤트입니다. 예를 들어, 모든 INSERT 이벤트 또는 모든 DELETE 이벤트를 감사하도록 선택할 수 있습니다. 예를 들어, 데이터를 수정하는 모든 이벤트(INSERT/DELETE/UPDATE/UPSERT)는 감사하지만 데이터만 검색하는 문(SELECT)은 무시하는 것이 합리적일 수 있습니다.
두 번째는 쿼리 엔진에 의해 노출된 API에 해당하는 이벤트입니다. N1QL 쿼리 엔진은 일반적으로 시스템 모니터링에 사용할 수 있는 여러 API를 제공합니다. 이러한 각 API 엔드포인트는 별도의 이벤트 유형입니다. 예를 들어 /admin/stats 엔드포인트와 /admin/ping 엔드포인트가 있습니다. 이러한 API에 대한 액세스를 감사할지 여부는 별도로 제어할 수 있습니다.
일반 쿼리
간단한 SELECT 문을 감사하는 것으로 시작하겠습니다.
관리자 콘솔의 "버킷" 페이지로 이동하여 "test"(따옴표 제외)라는 이름의 버킷을 만듭니다. 메모리 할당량은 100MB면 충분합니다. 그런 다음 쿼리로 이동하여 새 버킷에 기본 인덱스를 만들어 N1QL 쿼리를 실행할 수 있도록 합니다.
테스트에 기본 인덱스 생성
감사 구성 화면으로 돌아가서 상단의 "이벤트 감사 및 로그에 쓰기"를 선택하고 "N1QL 이벤트" 아래의 "SELECT 문" 옵션을 선택합니다. 그런 다음 화면 하단의 "저장"을 누릅니다.
그런 다음 다음과 같이 쿼리를 실행합니다.
curl http://localhost:8093/query/service -d "statement=select * from test" -u 관리자:비밀번호
이제 감사 로그를 살펴봅시다. 감사 구성 화면의 '대상 로그 디렉터리' 필드에는 감사 로그가 저장된 디렉터리가 있습니다. "tail" 명령을 사용하여 이 디렉터리에 있는 감사 로그의 마지막 몇 개의 레코드를 표시하겠습니다. Mac 시스템에서는 이 명령이 작동합니다:
꼬리 ~/라이브러리/애플리케이션\ 지원/카우치베이스/var/lib/카우치베이스/로그/감사.로그
여러 줄의 긴 JSON 텍스트가 표시될 것입니다. 각 줄은 하나의 감사 레코드입니다. 마지막 줄은 저희가 보낸 명세서에 대한 레코드입니다. 서식을 다시 지정하면 다음과 같이 보입니다:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
{ "timestamp": "2018-03-14T05:53:34.976-07:00", "real_userid": { "source": "local", "user": "관리자" }, "requestId": "d0554df3-fd99-40f5-b911-b3e4f0faf050", "진술": "test에서 * 선택", "isAdHoc": true, "userAgent": "curl\/7.43.0", "node": "127.0.0.1:8091", "status": "성공", "metrics": { "elapsedTime": "822.147\u00b5s", "실행 시간": "785.755\u00b5s", "resultCount": 0, "결과 크기": 0 }, "id": 28672, "name": "SELECT 문", "설명": "N1QL SELECT 문이 실행되었습니다." } |
분야별로 살펴보겠습니다:
- "타임스탬프"는 쿼리 노드의 시간을 표시합니다.
- "real_userid"는 요청과 함께 제공된 사용자 자격 증명을 보여줍니다. 이 경우 기본 제공 사용자인 "관리자"입니다.
- "requestId"는 쿼리 엔진이 모든 요청에 대해 생성하는 UUID입니다. 이 ID는 매우 높은 확률로 고유합니다.
- "문"은 실제 실행한 문입니다.
- 이 경우 "isAdHoc"은 참이며, 준비된 문을 실행하는 것이 아니라 실제 실행을 위해 문을 보냈음을 나타냅니다.
- "userAgent"는 원래 요청의 사용자 에이전트 문자열입니다. 이는 요청이 SDK에서 왔는지, CBQ 셸에서 왔는지, 쿼리 워크벤치에서 왔는지 구분하는 데 유용합니다.
- "노드"는 요청이 수신된 IP 주소입니다.
- "상태"는 요청에 어떤 일이 일어났는지 보여줍니다. 이 경우에는 성공했습니다.
- "메트릭"은 결과에 대한 통계 집합입니다. 이는 원래 요청의 결과와 함께 전송된 메트릭과 일치합니다.
- "id"는 이벤트 유형 ID입니다. 모든 SELECT 쿼리에 대한 감사 레코드의 ID는 28672로 동일합니다.
- "name"은 이벤트 유형의 짧은 이름입니다. 이는 모든 SELECT 쿼리에서 동일하게 적용됩니다.
- "description"은 이벤트 유형의 긴 이름입니다. 이는 모든 SELECT 쿼리에서도 동일합니다.
쿼리 엔진은 요청당 여러 개의 자격 증명을 허용하지만 감사 기록은 한 명의 사용자만 제공한다는 점에 유의하세요. 이는 의도된 것입니다. 자격 증명이 버킷 단위였던 시절에는 N1QL에서 쿼리에 대해 여러 자격 증명을 허용했기 때문에 다중 버킷 조인을 위해서는 여러 자격 증명이 필요했습니다. 하지만 5.0 버전부터 RBAC에서는 더 이상 여러 개의 자격 증명이 필요하지 않습니다. 이전 버전과의 호환성을 위해 지원하지만, 이러한 경우를 처리하는 올바른 방법은 여러 버킷에 대한 자격 증명을 가진 사용자를 만들고 각 쿼리에 대해 그러한 사용자 한 명을 사용하는 것입니다. 감사된 쿼리에 여러 자격 증명을 사용해야 한다고 고집하는 경우 쿼리는 감사되지만 제공된 모든 자격 증명에 대해 별도의 감사 기록이 남게 됩니다. 이는 다소 불편하므로 이러한 경우 RBAC 권한을 사용하도록 권한 모델을 업데이트할 것을 강력히 권장합니다.
명세서 준비
이제 준비된 문이 있는 좀 더 정교한 경우를 고려해 보겠습니다. 먼저 감사 구성 화면으로 돌아가서 SELECT 및 PREPARE 문 감사를 켭니다. 화면 하단의 '저장'을 누르는 것을 잊지 마세요.
이제 먼저 문을 준비하겠습니다. 여기서는 이름이 "example"인 SELECT 문을 준비합니다. 이 문에는 이름 없는 매개변수가 있다는 점에 유의하세요.
curl http://localhost:8093/query/service -d "statement=prepare example as select * from test where one=?" -u 관리자:비밀번호
그런 다음 문에 인수를 제공하여 문을 실행합니다. 이 경우 문은 실행되지만 결과는 반환하지 않습니다.
curl http://localhost:8093/query/service -d 'prepared="example"&args=["bar"]'
이제 감사 로그를 다시 살펴보겠습니다.
꼬리 ~/라이브러리/애플리케이션\ 지원/카우치베이스/var/lib/카우치베이스/로그/감사.로그
로그에는 두 개의 이벤트가 표시되는데, 하나는 PREPARE에 대한 이벤트이고 다른 하나는 준비된 문에서 실행된 SELECT에 대한 이벤트입니다:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
{ "timestamp": "2018-03-14T06:27:39.884-07:00", "real_userid": { "source": "local", "user": "관리자" }, "requestId": "9f76b8c2-ed9f-42f8-bc5c-31fb3326a661", "진술": "준비 예제를 test에서 select * from where one=?", "isAdHoc": true, "userAgent": "curl\/7.43.0", "node": "127.0.0.1:8091", "status": "성공", "metrics": { "elapsedTime": "6.591126ms", "실행 시간": "6.515079ms", "resultCount": 1, "결과 크기": 1279 }, "id": 28674, "name": "PREPARE 문", "설명": "N1QL PREPARE 문이 실행되었습니다." } { "timestamp": "2018-03-14T06:27:52.992-07:00", "real_userid": { "source": "내부", "user": "알 수 없음" }, "requestId": "56c5278b-5842-45a9-8549-5c7f52f109a7", "진술": "", "positionalArgs": [ "\"bar\"" ], "isAdHoc": false, "userAgent": "curl\/7.43.0", "node": "127.0.0.1:8091", "status": "성공", "metrics": { "elapsedTime": "1.363373ms", "실행 시간": "1.334763ms", "resultCount": 0, "결과 크기": 0 }, "id": 28672, "name": "SELECT 문", "설명": "N1QL SELECT 문이 실행되었습니다." } |
감사 레코드의 필드는 앞서 실행한 SELECT 문과 유사하지만 두 개의 필드가 주목할 만합니다:
- "positionalArgs"에는 쿼리와 함께 제공된 인수가 포함됩니다.
- 이 경우 SELECT가 이전에 전송된 준비된 문에서 실행되었으므로 "isAdHoc"은 거짓입니다.
API 요청
다음으로 쿼리 엔진 API 중 하나를 감사해 보겠습니다. 감사 구성 페이지로 이동하여 "/admin/ping API 요청" 이벤트 유형을 켭니다. 페이지 하단에 구성을 저장하는 것을 잊지 마세요.
이제 핑을 보내세요:
curl -v http://localhost:8093/admin/ping
하단의 '{}'가 전체 결과이므로 많은 것을 기대하지 마세요:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
* 시도 중 ::1... * 연결됨 에 localhost (::1) 포트 8093 (#0) > GET /관리자/ping HTTP/1.1 > 호스트: localhost:8093 > 사용자-에이전트: curl/7.43.0 > 수락: */* > < HTTP/1.1 200 확인 < 날짜: 수요일, 14 3월 2018 13:54:24 GMT < 콘텐츠-길이: 2 < 콘텐츠-유형: 텍스트/plain; 문자셋=utf-8 < * 연결 로컬호스트를 호스트하는 #0은 그대로 유지됨 {} |
그런 다음 감사 로그를 살펴보겠습니다(다시 Mac의 위치를 사용):
꼬리 ~/라이브러리/애플리케이션\ 지원/카우치베이스/var/lib/카우치베이스/로그/감사.로그
형식이 지정된 결과 감사 로그 메시지는 다음과 같습니다:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "timestamp": "2018-03-14T06:54:24.887-07:00", "real_userid": { "source": "내부", "user": "알 수 없음" }, "httpMethod": "GET", "httpResultCode": 200, "errorMessage": "", "id": 28697, "name": "/admin/ping API 요청", "설명": "/admin/ping에서 API에 HTTP 요청이 이루어졌습니다." } |
여기서 "timestamp" 및 "real_userid" 필드는 SELECT 예제에서와 같이 작동합니다. "httpMethod"는 HTTP 요청 유형입니다. "httpResultCode" 및 "errorMessage"는 요청에 어떤 일이 발생했는지 나타냅니다. "아이디", "이름", "설명"은 감사 이벤트에 고유하며, 이러한 필드는 /admin/ping 이벤트에 대해 만들어진 모든 감사 레코드에 대해 동일하게 적용됩니다.
포워드 필터링
(이것은 고급 주제입니다. 이 섹션의 자료를 몰라도 N1QL 감사를 효과적으로 사용할 수 있습니다. 하지만 고급 사용자라면 내부를 살펴보는 것이 흥미로울 수 있습니다.)
감사는 각 서버에서 감사 악마라는 실행 파일에 의해 제어됩니다. 감사 악마는 감사 로그에 모든 레코드를 생성합니다. 5.0에서는 감사 악마가 이벤트의 모든 필터링을 담당했고, 클라이언트는 감사 가능한 모든 이벤트에 대한 기록을 전송하면 감사 악마가 필터링 구성에 따라 로그에 감사 기록을 만들거나 만들지 않았습니다. 안타깝게도 감사가 고도로 필터링되어 클라이언트가 잠재적으로 감사 대상이 될 수 있는 많은 작업을 수행하는 경우 이는 매우 비효율적입니다. 쿼리 엔진과 같은 클라이언트는 수백만 개의 레코드를 생성하지만 도착하자마자 감사 악마에 의해 버려질 수 있습니다.
이 문제를 완화하기 위해 5.5에서는 Couchbase가 포워드 필터링을 지원합니다. 쿼리 엔진은 현재 감사 구성을 인식하고 현재 감사된 레코드만 감사 데몬으로 보냅니다. 또한 새 구성을 수신했으며 이를 인식하고 있음을 나타내는 특수 감사 레코드를 보냅니다.
이러한 이중 필터링으로 인해 감사 로그에 두 가지 유형의 구성 레코드가 표시될 수 있습니다. 이와 같은 레코드는 감사 데몬이 새 구성을 수신했음을 나타냅니다:
1 2 3 4 5 6 7 8 9 10 |
{"rotate_size":20971520,"log_path":"/사용자/요한라슨/도서관/애플리케이션 지원/카우치베이스/var/lib/카우치베이스/로그","rotate_interval":86400, "disabled_userids":[],"auditd_enabled":true, "disabled":[20485,20488,20489,20490,20491,28673,28675,28676,28677,28678,28679,28680,28681,28682, 28683,28684,28685,28686,28687,28688,28689,28690,28691,28692,28693,28694,28695,28697,28698,28699, 28700,28701,28702,32770,32771,32772,32780], "enabled:[20480,20482,20483,28672,28674,32768,32769,32773,32774,32775,32776,32777,32778,32779,32781,32782], "real_userid":{"출처":"ns_서버","사용자":"관리자"},"세션ID":"8b3d16bffa8444ce596b64a78c0185f7", "원격":{"IP":"127.0.0.1","포트":52153}, "타임스탬프":"2018-03-14T06:25:30.370-07:00","id":8240,"이름":"구성된 감사 daemon", "설명":"로드 구성 파일 에 대한 감사 daemon"} |
그리고 이와 같은 레코드는 쿼리 엔진이 새 구성을 수신했음을 나타냅니다:
1 2 3 |
{"timestamp":"2018-03-14T06:25:30.427-07:00", "real_userid":{"source":"","user":""},"uuid":"26571424","id":28703, "name":"N1QL 구성","설명":"N1QL이 지정된 uuid로 감사 구성을 사용하고 있음을 나타냅니다."} |
구성을 식별하는 UUID에 주목하세요. 다음과 같이 구성에서 이 UUID를 얻을 수 있습니다:
curl http://localhost:8091/pools/default -u 관리자:비밀번호
"auditUid" 필드를 찾습니다.
다음과 같이 전체 감사 구성을 얻을 수 있습니다:
curl http://localhost:8091/settings/audit -u 관리자:비밀번호
1 2 3 4 5 6 7 |
{"disabled":[20485,20488,20489,20490,20491,28673,28675,28676,28677,28678, 28679,28680,28681,28682,28683,28684,28685,28686,28687,28688,28689, 28690,28691,28692,28693,28694,28695,28698,28699,28700,28701,28702, 32770,32771,32772,32780], "uid":"18635804","auditdEnabled":true,"disabledUsers":[], "logPath":"/사용자/요한라슨/도서관/애플리케이션 지원/카우치베이스/var/lib/카우치베이스/로그", "회전 간격":86400,"rotateSize":20971520} |
감사 로그 로드
카우치베이스 서버는 현재 감사 레코드에 대해 서버의 파일이라는 하나의 대상만 지원합니다. 그러나 때로는 감사 레코드를 데이터베이스 자체로 가져오는 것이 유용할 수 있습니다. 감사 레코드는 JSON이므로 어렵지 않습니다. 하지만 로그를 로드하려면 cbimport라는 유틸리티를 사용해야 합니다.
Mac의 표준 위치에 감사 로그가 있고 '테스트' 버킷을 만들었다는 가정 하에, 이 주문은 audit.log 파일을 '테스트' 버킷에 로드합니다:
/Applications/CouchBase\ Server.app/Contents/Resources/couchbase-core/bin/cbimport json -c http://localhost:8091 -u 관리자 -p 비밀번호 -b 테스트 -g "#UUID#" -d file:///Users/johanlarson/Library/Application\ Support/CouchBase/var/lib/couchbase/logs/audit.log -f lines
이는 받아들이기에는 다소 많은 양이며 다른 시스템에서 약간 다른 변형이 필요하므로 단계별로 살펴 보겠습니다.
- /어플리케이션/카우치베이스\ 서버.앱/콘텐츠/리소스/couchbase-core/bin/cbimport 는 Mac에서 cbimport 명령의 전체 경로입니다. 다른 시스템의 경우 유틸리티는 다른 곳에 있습니다. 다음을 참조하세요. 이 문서.
- -c http://localhost:8091 는 카우치베이스가 실행되고 있는 서버의 URL입니다.
- -u 관리자 -p 비밀번호 는 데이터를 업로드하는 사용자의 사용자 아이디와 비밀번호입니다(이 경우 기본 관리자).
- -b 테스트 는 데이터를 업로드할 버킷의 이름입니다.
- -g "#UUID#" 는 버킷에 입력된 각 문서에 대해 생성할 키의 유형입니다. 이 경우에는 UUID를 사용하고 있지만 다른 많은 옵션이 있습니다. 버킷의 cbimport 문서에서 자세한 내용을 확인하세요.
- -d file:///Users/johanlarson/Library/Application\ Support/Couchbase/var/lib/couchbase/logs/audit.log 는 감사 로그의 위치를 가리키는 파일 URL입니다. URL 경로에 공백을 허용하기 위해 슬래시 세 개와 백슬래시를 사용하세요. 감사 로그를 포함한 로그는 시스템마다 다른 표준 디렉터리에 배치됩니다. 다음을 참조하세요. 이 문서 에서 자세한 내용을 확인하세요.
감사 기록이 시스템에 있으면 다른 데이터와 마찬가지로 쿼리할 수 있으며, 쿼리 워크벤치로 이동하여 사용해 보세요.
이 쿼리는 얼마나 많은 감사 레코드가 있는지 보여줍니다:
SELECT COUNT(*) AS NUM FROM TEST
그리고 이 쿼리는 감사 레코드 유형별로 개수를 세분화합니다:
이름별 테스트 그룹에서 이름, 카운트(*)를 NUM으로 선택합니다.
요약
- 쿼리 엔진에 대한 요청은 다음 날짜부터 감사할 수 있습니다. 카우치베이스 서버 5.5 EE.
- 감사는 일반적으로 이벤트 유형별 필터링과 사용자 화이트리스트를 지원합니다.
- 요청은 쿼리 유형 및 API 엔드포인트별로 이벤트로 표시됩니다.
- N1QL 문 감사에 대한 추가 문서를 사용할 수 있습니다. 여기.
- Couchbase Server 5.5 다운로드 여기를 클릭하세요.
선택적 문서만 감사할 수 있나요? 예를 들어 유형이 'hotels'인 문서만 감사하고 싶습니다.
아니요, 문서 특성별로 선택할 수 없습니다.