# 고객 구성 Snowflake 통합 (레거시)
{% hint style="warning" %}
Panther는 새 계정에 대해 이 방법을 지원하지 않으며, 기존 고객을 다음 중 하나로 이전할 예정입니다. [지원되는 방법](https://docs.panther.com/ko/system-configuration/panther-deployment-types/legacy-configurations/snowflake-setup) 향후.
{% endhint %}
## 개요
이 구성에서는 Panther가 접근 권한이 없으며, Panther를 대신하여 명령을 실행하려면 데이터베이스 관리자(DBA)가 필요합니다.
이 가이드는 이미 AWS에 Snowflake 인스턴스가 있다고 가정합니다.
이상적으로는 Panther 배포와 Snowflake 인스턴스가 동일한 AWS 리전에 있어야 합니다. Panther와 Snowflake를 같은 리전에 두면 쿼리 및 데이터 이동에 대한 지연 시간(리전 간 통신과 비교하여)이 줄어듭니다.
Panther는 Snowflake 인스턴스에 접근하기 위해 두 개의 Snowflake 사용자/역할을 사용합니다:
1. 쿼리를 위한 읽기 전용 사용자/역할
2. 새 로그 소스가 Panther에 등록될 때 테이블을 생성할 수 있도록 Panther 데이터베이스에만 엄격한 권한을 가진 관리자 사용자/역할.
Snowflake에서는 테이블 접근을 공유할 수 있습니다. 이를 통해 비즈니스 데이터와 보안 데이터를 Panther에서 쿼리할 수 있습니다(다음을 통해 `PANTHER_READ_ONLY` 역할).
자체 Snowflake 인스턴스를 관리하는 경우, Panther가 수집한 데이터로 테이블과 뷰를 생성할 수 있습니다. 이러한 사용자 정의 객체를 Panther 데이터베이스 안에 두지 마세요. 예상치 못한 테이블과 뷰는 오류를 유발합니다. 대신 Panther가 아닌 데이터베이스에 생성한 뒤 Panther와 공유하세요.
{% hint style="danger" %}
접두사로 사용자 또는 기타 데이터베이스 객체를 생성하지 마세요 `PANTHER_`.
{% endhint %}
## 기존 고객 관리형 Snowflake 통합을 구성하는 방법
#### 1. Panther에서 구성 정보 수집
1. Panther 콘솔에 로그인합니다.
2. 오른쪽 상단의 톱니바퀴 아이콘을 클릭합니다.
3. 드롭다운 메뉴에서 **일반**.
에서 다음 정보를 찾을 수 있습니다:
* Snowflake ReadOnly Lambda Role ARN
* Snowflake Admin Lambda Role ARN
* Lookup Tables Lambda Role ARN
이 ARN들을 잘 보관해 두세요. 나중에 사용합니다.
#### 2. Snowflake에서 구성 정보 수집
Panther를 구성하려면 다음 항목을 가져와야 합니다. `SNOWFLAKE_IAM_USER` 를 Snowflake에서 가져와야 합니다.
Snowflake SQL 셸에서 아래 SQL을 실행하되, 다음을 바꿔서 사용하세요. `myaccountid` 를 AWS 계정 ID로, 그리고 `myaccountregion` 를 해당 계정의 리전으로 바꾸세요:
```sql
SELECT system$get_aws_sns_iam_policy('arn:aws:sns:myaccountregion:myaccountid:panther-processed-data-notifications');
```
다음과 유사한 응답이 표시되어야 합니다:
```javascript
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"1",
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam::87654321XXXX:user/k7m2-s-v2st0722"
},
"Action":["sns:Subscribe"],
"Resource":["arn:aws:sns:us-west-1:12345678XXXX:panther-processed-data-notifications"]
}
]
}
```
위 예에서 `SNOWFLAKE_IAM_USER` 은(는) `AWS` 속성 `arn:aws:iam::87654321XXXX:user/k7m2-s-v2st0722`. 이 내용을 잘 보관하세요. 나중 단계에서 이것을 사용할 것입니다.
#### 3. Snowflake에서 Panther 데이터베이스를 생성합니다
Snowflake SQL 셸에서 실행하세요:
```sql
USE ROLE SYSADMIN;
---------------- 데이터베이스
CREATE database IF NOT EXISTS panther_logs;
CREATE database IF NOT EXISTS panther_룰_matches;
CREATE database IF NOT EXISTS panther_룰_errors;
CREATE database IF NOT EXISTS panther_cloudsecurity;
CREATE database IF NOT EXISTS panther_monitor;
CREATE database IF NOT EXISTS panther_views;
CREATE database IF NOT EXISTS panther_stored_procedures;
CREATE database IF NOT EXISTS panther_lookups;
CREATE database IF NOT EXISTS panther_signals;
```
#### 4. Snowflake에서 읽기 전용 역할과 관리 역할을 생성합니다
{% hint style="warning" %}
***1.18로 업그레이드하는 자체 호스팅 Snowflake 배포 고객의 경우***
Snowflake 데이터 클라우드를 사용하는 자체 호스팅 고객은 데이터베이스 관리자가 다음 권한 세트를 추가하거나, 최신 버전의 설정 지침을 반영하도록 자동화 스크립트를 업데이트해야 합니다:
{% endhint %}
```yaml
USE ROLE SECURITYADMIN;
GRANT CREATE STAGE, CREATE PIPE ON ALL SCHEMAS IN DATABASE PANTHER_MONITOR
TO ROLE panther_admin_role;
```
***참고***: 반드시 업데이트하세요 `` 아래 SQL 블록 첫 줄의 값을 Panther가 사용하도록 원하는 Snowflake 웨어하우스 이름으로 설정하세요.
전용 Panther 웨어하우스(예: PANTHER\_WH)를 생성하는 것을 권장합니다. 그러면 비용을 쉽게 추적하고 다른 Snowflake 리소스와 독립적으로 용량을 조정할 수 있습니다.
Snowflake SQL 셸에서 실행하세요:
```sql
SET WAREHOUSE_NAME = '';
USE ROLE SECURITYADMIN;
--------------- panther_readonly_role 생성
CREATE ROLE IF NOT EXISTS panther_readonly_role;
---------------- panther_readonly_role에 대한 권한 부여
-- 웨어하우스
GRANT USAGE
ON WAREHOUSE IDENTIFIER($WAREHOUSE_NAME)
TO ROLE panther_readonly_role;
-- panther_logs
GRANT USAGE
ON DATABASE panther_logs
TO ROLE panther_readonly_role;
GRANT USAGE
ON SCHEMA panther_logs.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON ALL TABLES IN SCHEMA panther_logs.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON ALL VIEWS IN SCHEMA panther_logs.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON FUTURE TABLES IN SCHEMA panther_logs.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON FUTURE VIEWS IN SCHEMA panther_logs.public
TO ROLE panther_readonly_role;
-- panther_룰_matches
GRANT USAGE
ON DATABASE panther_룰_matches
TO ROLE panther_readonly_role;
GRANT USAGE
ON SCHEMA panther_룰_matches.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON ALL TABLES IN SCHEMA panther_룰_matches.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON ALL VIEWS IN SCHEMA panther_룰_matches.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON FUTURE TABLES IN SCHEMA panther_룰_matches.public
TO ROLE panther_readonly_role;
GRANT SELECT
ON FUTURE VIEWS IN SCHEMA panther_룰_matches.public
TO ROLE panther_readonly_role;
-- panther_룰_errors
GRANT USAGE
ON DATABASE panther_룰_errors
TO ROLE panther_readonly_role;
GRANT USAGE
SCHEMA panther_룰_errors.public에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_룰_errors.public의 모든 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_룰_errors.public의 모든 VIEW에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_룰_errors.public의 향후 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_룰_errors.public의 향후 VIEW에서
TO ROLE panther_readonly_role;
-- panther_cloudsecurity
GRANT USAGE
DATABASE panther_cloudsecurity에서
TO ROLE panther_readonly_role;
GRANT USAGE
SCHEMA panther_cloudsecurity.public에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_cloudsecurity.public의 모든 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_cloudsecurity.public의 모든 VIEW에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_cloudsecurity.public의 향후 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_cloudsecurity.public의 향후 VIEW에서
TO ROLE panther_readonly_role;
--panther_monitor
GRANT USAGE
DATABASE PANTHER_MONITOR에서
PANTHER_READONLY_ROLE에 부여;
GRANT USAGE
SCHEMA PANTHER_MONITOR.PUBLIC에서
PANTHER_READONLY_ROLE에 부여;
GRANT SELECT
SCHEMA PANTHER_MONITOR.PUBLIC의 모든 TABLE에 대해
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA PANTHER_MONITOR.PUBLIC의 모든 VIEW에 대해
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA PANTHER_MONITOR.PUBLIC의 향후 TABLE에 대해
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA PANTHER_MONITOR.PUBLIC의 향후 VIEW에 대해
TO ROLE panther_readonly_role;
-- panther_views
GRANT USAGE
DATABASE panther_views에서
TO ROLE panther_readonly_role;
GRANT USAGE
SCHEMA panther_views.public에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_views.public의 모든 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_views.public의 모든 VIEW에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_views.public의 향후 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_views.public의 향후 VIEW에서
TO ROLE panther_readonly_role;
-- panther_lookups
GRANT USAGE
DATABASE panther_lookups에서
TO ROLE panther_readonly_role;
GRANT USAGE
SCHEMA panther_lookups.public에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_lookups.public의 모든 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_lookups.public의 모든 VIEW에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_lookups.public의 향후 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_lookups.public의 향후 VIEW에서
TO ROLE panther_readonly_role;
-- panther_signals
GRANT USAGE
DATABASE panther_signals에서
TO ROLE panther_readonly_role;
GRANT USAGE
SCHEMA panther_signals.public에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_signals.public의 모든 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_signals.public의 모든 VIEW에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_signals.public의 향후 TABLE에서
TO ROLE panther_readonly_role;
GRANT SELECT
SCHEMA panther_signals.public의 향후 VIEW에서
TO ROLE panther_readonly_role;
--------------- panther_admin_role 생성
존재하지 않으면 ROLE panther_admin_role 생성;
ROLE panther_readonly_role 부여
TO ROLE panther_admin_role;
---------------- panther_admin_role에 대한 부여
-- panther_logs
CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY, ADD SEARCH OPTIMIZATION 생성 권한
DATABASE panther_logs의 모든 SCHEMA에
TO ROLE panther_admin_role;
-- panther_룰_matches
CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY, ADD SEARCH OPTIMIZATION 생성 권한
DATABASE panther_룰_matches의 모든 SCHEMA에
TO ROLE panther_admin_role;
-- panther_룰_errors
CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY, ADD SEARCH OPTIMIZATION 생성 권한
DATABASE panther_룰_errors의 모든 SCHEMA에
TO ROLE panther_admin_role;
-- panther_cloudsecurity
CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY, ADD SEARCH OPTIMIZATION 생성 권한
DATABASE panther_cloudsecurity의 모든 SCHEMA에
TO ROLE panther_admin_role;
-- panther_monitor
CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY, ADD SEARCH OPTIMIZATION 생성 권한
데이터베이스 PANTHER_MONITOR의 모든 스키마에서
TO ROLE panther_admin_role;
SELECT, INSERT, UPDATE 권한 부여
스키마 PANTHER_MONITOR.PUBLIC의 모든 테이블에서
역할 PANTHER_ADMIN_ROLE에 부여;
SELECT, INSERT, UPDATE 권한 부여
스키마 PANTHER_MONITOR.PUBLIC의 향후 모든 테이블에서
역할 PANTHER_ADMIN_ROLE에 부여;
-- panther_lookups
CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY, ADD SEARCH OPTIMIZATION, CREATE PROCEDURE, CREATE FUNCTION 권한 부여
데이터베이스 PANTHER_LOOKUPS의 모든 스키마에서
역할 PANTHER_ADMIN_ROLE에 부여;
SELECT, INSERT, UPDATE 권한 부여
스키마 PANTHER_LOOKUPS.PUBLIC의 모든 테이블에서
역할 PANTHER_ADMIN_ROLE에 부여;
SELECT, INSERT, UPDATE 권한 부여
스키마 PANTHER_LOOKUPS.PUBLIC의 향후 모든 테이블에서
역할 PANTHER_ADMIN_ROLE에 부여;
-- panther_signals
CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY, ADD SEARCH OPTIMIZATION, CREATE PROCEDURE, CREATE FUNCTION 권한 부여
데이터베이스 PANTHER_SIGNALS의 모든 스키마에서
역할 PANTHER_ADMIN_ROLE에 부여;
SELECT, INSERT, UPDATE 권한 부여
스키마 PANTHER_SIGNALS.PUBLIC의 모든 테이블에서
역할 PANTHER_ADMIN_ROLE에 부여;
SELECT, INSERT, UPDATE 권한 부여
스키마 PANTHER_SIGNALS.PUBLIC의 향후 모든 테이블에서
역할 PANTHER_ADMIN_ROLE에 부여;
-- panther_views
CREATE VIEW, MODIFY 권한 부여
데이터베이스 panther_views의 모든 스키마에서
TO ROLE panther_admin_role;
-- panther_stored_procedures
데이터베이스 panther_stored_procedures에 USAGE 권한 부여
TO ROLE panther_admin_role;
CREATE PROCEDURE, CREATE FUNCTION, MODIFY, USAGE 권한 부여
데이터베이스 panther_stored_procedures의 모든 스키마에서
TO ROLE panther_admin_role;
-- 이를 통해 panther_admin_role이 Panther의 s3 버킷을 위한 스토리지 통합을 생성할 수 있습니다
-- 참고: 이 권한 부여는 Panther의 초기 온보딩이 성공적으로 완료된 후 제거할 수 있습니다
USE ROLE ACCOUNTADMIN;
ROLE panther_admin_role에 ACCOUNT에 대한 CREATE INTEGRATION 권한 부여;
-- panther가 Snowflake의 감사 데이터베이스에 접근할 수 있도록 허용(선택 사항)
ROLE panther_readonly_role에 snowflake 데이터베이스의 IMPORTED PRIVILEGES 권한 부여;
```
#### 5. Snowflake에 읽기 전용 사용자와 관리자 사용자 생성
참고: 아래에 `` 및 `` 를 설정하세요. Snowflake SQL 셸에서 실행:
```sql
USE ROLE SECURITYADMIN;
-- panther_readonly 사용자
CREATE USER IF NOT EXISTS panther_readonly password='';
ROLE panther_readonly_role 부여
USER panther_readonly에 부여;
ALTER USER panther_readonly
SET default_role = panther_readonly_role;
-- panther_admin 사용자
CREATE USER IF NOT EXISTS panther_admin password='';
ROLE panther_admin_role 부여
USER panther_admin에;
ALTER USER panther_admin
SET default_role = panther_admin_role;
ALTER USER PANTHER_ADMIN
SET TIMEZONE = 'UTC';
```
#### 6. AWS Secrets 생성을 더 쉽게 하기 위한 저장 프로시저 생성(선택 사항)
AWS Secret Manager에 복사해서 붙여넣을 수 있는 JSON 문서를 생성하는 이 저장 프로시저를 정의합니다(입력 타이핑 절약). Snowflake SQL 셸에서 실행:
```sql
USE ROLE SYSADMIN;
CREATE or replace FUNCTION panther_stored_procedures.public.generate_secret(USN VARCHAR, PWD VARCHAR, WHS VARCHAR, HST VARCHAR)
OBJECT 반환
SQL 언어
STRICT
AS
$$
SELECT object_construct('account', current_account(),
'user', USN ,
'password', PWD ,
'host',TRIM(REPLACE(HST,'https://'),'/'),
'port','443',
'warehouse',WHS) AS SECRET
$$;
-- 여기에서 값을 사용자 비밀번호, 사용할 컴퓨트 웨어하우스, 그리고 호스트명에 맞게 사용자 지정하세요.
-- 호스트명은 일반적으로 클러스터에 로그인할 때 사용한 URL의 ".snowflakecomputing.com" 형식입니다.
-- SELECT panther_stored_procedures.public.generate_secret('panther_readonly','password123','COMPUTE_WH','.snowflakecomputing.com');
```
#### 7. Panther Snowflake Secrets를 위한 AWS 계정에 KMS 키를 생성합니다
이 키는 8단계의 일부로 AWS 계정에 저장할 Snowflake 시크릿을 암호화하는 데 사용됩니다.
1. AWS 계정에 로그인합니다
2. (선택 사항) Snowflake 계정이 있는 동일한 리전으로 이동합니다
3. KMS 서비스로 이동합니다
4. 을 클릭합니다 `키 생성`
5. 을 선택합니다 `대칭형` 를 유형으로 선택한 다음 `다음`
6. 별칭을 다음으로 설정합니다 `panther-secret`. 클릭하세요 `다음`. 다음 페이지에서 `다음` (기본값 수락)
7. 을 클릭합니다 `다른 AWS 계정 추가` 를 클릭하고 Panther가 설치된 계정 ID를 입력합니다.
8. 을 클릭한 다음 `다음` 를 클릭합니다 `완료`.
#### 8. 읽기 전용 사용자 AWS Secret과 관리자 사용자 AWS Secret을 생성합니다
다음을 사용하게 됩니다 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) 를 사용하여 Snowflake 사용자 비밀번호를 저장합니다. 이는 Panther 계정의 단일 Lambda 함수에서만 접근할 수 있도록 구성됩니다.
아래 과정을 다음 항목에 대해 각각 한 번씩 반복합니다. `panther_readonly` 사용자와 한 번, 그리고 `panther_admin` 사용자에 대해 한 번 수행합니다.
* 콘솔을 통해 AWS Secrets Manager에 접속하여 페이지에서 다음을 선택합니다. `새 시크릿 저장` 버튼을 클릭합니다.
* 제목이 다음과 같은 페이지가 표시됩니다. `새 시크릿 저장`. 다음을 선택합니다. `기타 유형의 시크릿` 을 유형 목록에서 선택합니다. 다음 키/값 쌍을 지정합니다:
| 필드 | 설명 |
| :-------: | ------------------------------------------------------------------------------------------------------------------- |
| `account` | Snowflake 계정의 이름입니다. 이는 다음을 실행하여 찾을 수 있습니다. `SELECT CURRENT_ACCOUNT()` |
| `사용자` | 이전에 생성한 Snowflake 사용자, 또는 `panther_readonly` 또는 `panther_admin` |
| `비밀번호` | 이전에 생성한 Snowflake 사용자 비밀번호 |
| `호스트` | 이는 일반적으로 `.snowflakecomputing.com` 클러스터에 로그인할 때 사용한 URL에서 가져옵니다. 제거하세요 `https://` 및 뒤에 오는 모든 `/` 호스트명에서. |
| `포트` | 사용 `443` 별도로 구성하지 않은 경우 |
| `웨어하우스` | 활성 Snowflake 웨어하우스의 이름 |
위 항목을 직접 입력하거나, Snowflake SQL 셸에서 다음 명령을 실행하여 지정된 4개 매개변수의 적절한 값( `account` 및 `포트` 는 자동으로 채워져야 합니다). 다음에 대해 한 번 수행하세요. `panther_readonly` 사용자와 한 번, 그리고 `panther_admin`:
```sql
SELECT panther_stored_procedures.public.generate_secret(,,,);
```
그런 다음 결과를 2개의 비밀 항목 각각의 "plaintext" 편집기 탭에 복사하여 붙여넣을 수 있습니다.
***참고***: 6개 필드(*계정, 호스트, 비밀번호, 포트, 사용자, 웨어하우스*)가 모두 입력되어 있고 올바른 값인지 확인하세요. 그렇지 않으면 Panther 람다가 Snowflake에 연결하는 데 문제가 발생할 수 있습니다.
* "암호화 키 선택"에서 `panther-secret` 을(를) 드롭다운에서 선택하세요.
* 시크릿 키/값을 입력하세요.
* 을 클릭한 다음 `다음`.
* 시크릿의 이름과 설명을 입력하라는 화면이 표시됩니다. 이를 입력한 다음 `다음`.
* AWS Secrets Manager가 시크릿을 얼마나 자주 교체할지 설정한 다음 **다음**.
* 마지막으로 개요 화면이 표시됩니다. 맨 아래로 스크롤하여 `저장` 버튼.
#### 시크릿의 권한 업데이트
두 개의 Panther AWS 시크릿에 대한 권한을 구성해야 하며, 그렇게 하면 특정 Panther Lambda만 Snowflake 시크릿에 접근할 수 있습니다.
Panther `panther-snowflake-api` 는 다음을 사용할 것입니다. `panther_readonly` 사용자는 사용자 쿼리에 사용되는 반면, `panther-snowflake-admin-api` 는 다음을 사용할 것입니다. `panther_admin` 사용자는 새 로그 소스가 온보딩될 때 테이블을 생성하는 데 사용됩니다.
그 `panther-lookup-tables-api` Snowflake에서 조회 테이블을 관리하기 위해 해당 권한을 사용합니다.
콘솔로 이동하여 위에서 만든 각 시크릿을 선택하세요. 개요 화면에서 다음을 클릭합니다. `권한 편집` 버튼. 아래 정책 JSON을 복사하고, 적절한 항목으로 바꿉니다. ``다음 중 하나:
* `panther-snowflake-api` 첫 번째 단계에서 수집한 역할
* `panther-snowflake-admin-api` 첫 번째 단계에서 수집한 역할
다음을 대체합니다 `` 와 함께 `panther-lookup-tables-api` 첫 번째 단계에서 수집한 룰
값으로 `` 업데이트 중인 비밀의 ARN을 사용하세요.
```javascript
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"AWS": "" },
"Action": "secretsmanager:GetSecretValue",
"Resource": ""
},
{
"Effect": "Allow",
"Principal": {"AWS": "" },
"Action": "secretsmanager:GetSecretValue",
"Resource": ""
}
]
}
```
그다음 클릭하세요 **저장**.
다음 항목의 값을 메모해 두세요. `arn` 비밀에 대한 것입니다. 나중에 이것을 사용합니다.
#### 9. Snowflake가 활성화된 Panther 배포
#### SaaS 고객 관리형 배포 사용자
Panther 담당자(POC)에게 다음을 보내세요:
* `SNOWFLAKE_IAM_USER` 첫 번째 단계에서 수집한
* 에 대한 ARN `panther_readonly` 사용자 AWS Secret
* 에 대한 ARN `panther_admin` 사용자 AWS Secret
Panther POC가 Snowflake를 활성화하기 위해 이러한 설정으로 Panther를 다시 배포할 것입니다.
#### CloudPrem 사용자
자신의 계정에서 Panther를 실행하는 고객(이를 `CloudPrem이라고 합니다)은` 먼저 Panther의 초기 설정을 위해 마스터 템플릿을 배포해야 합니다. 마스터 템플릿을 배포한 후 아래와 같이 마스터 스택 파라미터를 구성하세요:
* 업데이트: `SnowflakeAPISecretARN` 파라미터를 위에서 생성한 비밀의 ARN으로 `panther_readonly` 사용자에 대해 한 번 수행합니다.
* 업데이트: `SnowflakeAdminAPISecretARN` 파라미터를 위에서 생성한 비밀의 ARN으로 `panther_admin` 사용자에 대해 한 번 수행합니다.
* 업데이트: `SnowflakeDestinationClusterARNs` 파라미터를 `` 의 초기 단계에서의 값으로
CloudFormation 스택에 대한 업데이트를 실행하세요.
#### Snowpipe 처리 검증
Panther가 Snowflake용으로 구성되면 다음 일곱 개의 데이터베이스가 있어야 합니다:
* `panther_logs`
* `panther_룰_matches`
* `panther_룰_errors`
* `panther_cloudsecurity`
* `panther_views`
* `pather_stored_procedures`
* `panther_monitor`
데이터가 정기적으로 처리되고 있다면 몇 분 안에 테이블에 데이터가 있어야 합니다. 이는 로그 수집 속도에 따라 달라집니다.
간단한 쿼리를 실행하여 데이터 수집이 제대로 작동하는지 빠르게 테스트할 수 있습니다:
```sql
SELECT count(1) AS c FROM panther_views.public.all_logs ;
```
구성은 다음에서 테스트할 수 있습니다. [데이터 탐색기](https://docs.panther.com/ko/search/data-explorer). 데이터가 있다고 알고 있는 테이블에 대해 동일한 쿼리를 몇 번 실행해 보세요(Snowflake 콘솔에서 확인).
#### 비밀 정보 회전
비밀 정보를 회전하려면 새 사용자를 생성하고 비밀 정보를 편집하여 기존 사용자와 비밀번호를 새 사용자와 비밀번호로 바꾸세요. Snowflake에서 기존 사용자를 삭제/비활성화하기 전에 한 시간 기다리세요.
%20(1).png?alt=media)
%20(2).png?alt=media)