Data Connection의 모든 주요 개념—에이전트, 소스, 싱크—는 Foundry에서 리소스로 관리됩니다. 이를 통해 프로젝트와 폴더 간에 이러한 리소스를 유연하게 구성할 수 있으며, Data Connection 리소스에 마킹과 같은 보안 기본 요소를 적용할 수 있습니다.
플랫폼 소유자는 Data Connection 리소스를 과도하게 공유하지 않도록 주의해야 합니다. 소스와 에이전트에서 보기 및 편집 권한을 갖는 사용자는 신뢰할 수 있는 파이프라인 개발자여야 합니다. 싱크에 의해 생성된 데이터 세트는 필요에 따라 하류 변환 프로젝트로 가져와져 에이전트나 소스에 대한 액세스를 공유하지 않고도 데이터에 액세스할 수 있습니다.
이 페이지에서는 Data Connection 리소스의 권한 작동 방식을 문서화합니다. 다음을 포함합니다:
아래 나열된 권한은 기본값입니다. 일부 환경에서는 커스텀 역할을 사용하여 기본 권한 동작이 변경되었을 수 있습니다.
소유자
에이전트의 소유자는 일반적으로 생성자이며 다음 권한이 부여됩니다:
에디터
에이전트의 에디터는 다음을 수행할 수 있습니다:
프로젝트의 에디터가 되려면 해당 프로젝트에서 에이전트를 생성해야 하지만, 프로젝트의 소유자가 되어야 해당 프로젝트 내의 에이전트를 관리할 수 있습니다. 이는 사용자가 에이전트를 생성한 다음 다운로드 링크를 생성하거나 에이전트에서 다른 관리 작업을 수행할 수 없게 될 수 있다는 것을 의미합니다.
뷰어
에이전트의 뷰어는 다음을 수행할 수 있습니다:
소유자
에디터
소스의 에디터는 다음을 수행할 수 있습니다:
소스 자격 증명이 허용하는 경우 싱크는 소스 시스템을 변경할 수 있다는 점에 유의하십시오(예: 디렉터리 또는 S3 소스에서 파일 삭제 또는 데이터베이스에서 임의의 SQL을 통한 데이터 삭제). 소스(또는 그것을 포함하는 프로젝트)에 대한 편집 권한을 데이터에 액세스하기 위해 사용하는 계정에 전체 액세스 권한을 부여할 사용자에게만 부여해야 합니다.
뷰어
싱크 권한은 관련 소스 및 출력 데이터 세트에서 파생됩니다.
소유자
에디터
뷰어
웹훅 권한은 관련 소스에서 완전히 상속됩니다.
기본적으로 웹훅을 실행하는 사용자만 Data Connection 애플리케이션의 기록 탭을 사용하여 응답을 볼 수 있습니다. webhooks:read-privileged-data 권한은 커스텀 또는 기본 역할에 추가되어 해당 역할을 갖는 사용자가 액세스할 수 있는 모든 웹훅에 대한 전체 요청 및 응답 기록을 볼 수 있게 할 수 있습니다. 기본 추천 설정은 이 권한을 가진 "웹훅 특권 데이터 뷰어"라는 새 역할을 추가하고, 관련 소스에서 전체 웹훅 기록을 볼 필요가 있는 사용자에게 이 역할을 부여하는 것입니다.
위에서 언급한 바와 같이, 리소스에는 그룹 및 마킹이 추가로 적용되어 액세스 제어 수준을 제공할 수 있습니다. 소스에 적용된 그룹 및 마킹은 해당 소스에서 싱크를 통해 생성된 데이터 세트로 전파됩니다. 이는 사용자가 소스에서 생성된 모든 데이터 세트의 데이터를 볼 수 없도록, 해당 소스에 적용된 모든 그룹 및 마킹에 액세스해야 한다는 것을 의미합니다.
소스에 다양한 민감도 수준의 데이터가 포함되어 있을 가능성이 높기 때문에, 해당 소스에서 사용 가능한 데이터에 적용되는 모든 그룹 및 마킹으로 소스를 표시하고, 변환을 사용하여 데이터를 정리하고 stop_propagating 및/또는 stop_requiring 기능을 사용하여 마킹을 해제하는 것이 좋습니다. 마킹 해제에 대한 자세한 내용은 마킹 제거 및 상속된 마킹 제거 가이드를 참조하십시오.
소스에 접근하는 것은 데이터에 접근하는 것이므로, 소스는 그것이 포함하는 모든 것에 적용되는 그룹 및 마킹으로 표시되어야 합니다.
간단한 요약으로, Data Connection의 주요 리소스는 에이전트와 소스입니다. 플러그인과 드라이버는 에이전트에 배포되어 기능을 확장합니다.
에이전트에 대해 권장되는 권한 설정은 다음 두 가지입니다: 조직별 단일 프로젝트 내의 모든 에이전트 또는 각 에이전트별로 독립된 프로젝트. 위의 다이어그램은 전자 옵션을 보여주며, 아래 가이드에서 각 옵션을 선택할 수 있는 이유를 설명합니다.
옵션 1: 조직별로 단일 프로젝트에 모든 에이전트를 배치합니다.
모든 에이전트를 단일 프로젝트에 배치하는 것은 가장 깔끔한 접근 방식이며, 모든 에이전트를 관리하는 사용자 그룹이 있는 경우 권장됩니다. 이를 통해 에이전트에 대한 액세스를 프로젝트 수준에서 제어할 수 있으며, 에이전트 다운스트림에서 소스와 싱크를 별도로 허용할 수 있습니다.
이 옵션을 선택하십시오. 에이전트 매니저와 모든 소스 에디터가 모든 에이전트에 대한 액세스를 갖는 것이 허용되는 경우에만 이 옵션을 선택하십시오. 에이전트에 소스를 배포하려면 사용자가 해당 에이전트에 대한 에디터 권한이 있어야 합니다.
옵션 2: 각 에이전트를 독립된 프로젝트에 배치합니다.
이 접근 방식은 에이전트 권한에 대한 완전한 세분화를 허용합니다. 또한 구조가 에이전트 관리의 진화 과정에서 어떤 시점에서든지 "그룹화"에서 벗어나지 않도록 보장합니다. 예를 들어, 소스에서 에이전트를 안전하게 할당/해제할 수 있으며, 앞으로 그룹 권한 변경에 대한 프로젝트 구조를 재구성할 필요가 없습니다.
에이전트를 관리하는 여러 그룹이 있고, 에이전트에 대한 액세스를 별도로 허용하려는 경우 이 접근 방식이 권장됩니다.
에이전트가 포함된 프로젝트의 에디터는 해당 에이전트에서 실행되는 새로운 소스와 싱크를 생성할 수 있습니다. 이 작업을 할 수 없어야 하는 사용자에게 프로젝트에서 에디터 역할을 부여하지 마십시오.
각 소스는 datasource 레이어에서 독립된 프로젝트에 있어야 합니다. 소스에서 정의된 각 싱크는 소스와 동일한 프로젝트 내부의 데이터 세트로 출력해야 합니다. 소스에 PII와 같은 민감한 데이터가 포함된 경우 소스에 마킹을 적용하여 출력 데이터 세트로 전파할 수 있습니다.
소스가 포함된 프로젝트의 에디터는 해당 소스의 새로운 싱크를 생성하고 기존 싱크를 편집할 수 있으며, 웹훅을 생성하고 Foundry의 다른 곳에서 사용하도록 구성할 수 있습니다.
싱크가 소스 자격 증명이 허용하는 경우 소스 시스템을 변경할 수 있다는 점에 유의하십시오. 예를 들어, 디렉터리 또는 S3 소스에서 파일 삭제 또는 데이터베이스에서 임의의 SQL을 통한 데이터 삭제를 수행할 수 있습니다.
소스(또는 그것을 포함하는 프로젝트)에 대한 편집 권한을 데이터에 액세스하기 위해 사용하는 계정에 전체 액세스 권한을 부여할 사용자에게만 부여해야 합니다.
플러그인 및 JDBC 드라이버에 대해 권장되는 권한 설정은 다음 두 가지입니다: 조직별 단일 프로젝트 내의 모든 리소스 또는 필요한 하나 이상의 에이전트와 함께 각 JDBC/드라이버를 프로젝트에 배치합니다.
옵션 1: 조직별로 단일 프로젝트에 모든 플러그인 및 드라이버를 배치합니다.
이 옵션은 모든 에이전트를 관리하는 사용자 그룹이 있는 경우 권장됩니다. 이를 통해 에이전트 관리자가 업로드된 모든 플러그인 및 드라이버에 액세스할 수 있습니다. 이 접근 방식은 모든 에이전트 관리자 간에 플러그인 및 드라이버에 대한 동등한 액세스가 허용되어야 하는 경우에만 선택해야 합니다.
이 접근 방식을 구현하는 권장 프로세스는 다음과 같습니다.
옵션 2: 각 플러그인 및 드라이버 유형을 독립된 프로젝트에 배치합니다.
이 접근 방식은 특정 "민감한" 플러그인 또는 드라이버를 다른 것과 별도로 허용할 수 있습니다. 이 접근 방식을 사용하는 경우, 필요한 에이전트 소유자에게 각 프로젝트에 대한 적절한 권한을 부여하여 에이전트에서 사용할 수 있도록 해야 합니다.