접근 조건이 파생 데이터에 전파되는 범위
접근 정책을 설계할 때에는 사용자가 원본을 읽을 수 있는지와, 읽은 값을 다른 결과에 사용했을 때 어떤 조건이 남는지를 나누어 판단해야 합니다. Foundry의 강제적 접근 통제는 플랫폼이 관리하는 데이터 의존 관계를 따라 보호 요건을 유지합니다. 프로젝트 역할과 행 또는 열의 읽기 정책은 적용 범위가 다릅니다.
강제적 접근 통제의 전파
| 통제 | 파생 관계에서의 동작 |
|---|---|
| 보안 표지 | 표지가 있는 입력으로 만든 데이터셋은 해당 표지를 데이터 접근 요건으로 상속합니다. 파일 계층으로 상속되는 표지도 별도로 적용합니다. |
| 보안 분류 기반 접근 제어(CBAC) | 데이터 분류는 자신의 파일 분류와 상류 데이터 분류를 결합합니다. 프로젝트 분류는 데이터 분류와 달리 프로젝트 밖 하류 데이터 의존 관계로 전파되지 않습니다. |
| 조직 | 조직으로 범위가 제한된 프로젝트와 관련 데이터 의존 관계에서 조직 접근 요건을 유지합니다. |
역할이나 애플리케이션 로직으로 강제적 접근 요건을 우회할 수는 없습니다. 사용자가 보호된 데이터를 읽는 지점에서 필요한 조직 소속, 보안 표지와 분류 자격을 충족해야 합니다. 권한 있는 담당자가 명시적으로 표지를 제거하는 변경은 별도의 접근 범위 확대 작업입니다.
CBAC를 모든 경우에 단일 열 태그로 취급하지 않습니다. 파일, 데이터와 프로젝트 분류는 발견과 데이터 읽기 및 전파 범위가 다릅니다. 보안 표지도 파일 자체의 요건과 상류 데이터에서 상속한 요건을 구분합니다.
재량적 역할과 읽기 정책
프로젝트 역할은 해당 프로젝트의 리소스에서 가능한 작업을 정하고 파일 계층을 따라 상속됩니다. 그러나 상류 프로젝트의 Viewer나 Owner 부여가 다른 프로젝트의 파생 데이터셋에 그대로 따라가는 것은 아닙니다.
행과 열의 읽기 정책에는 다음이 포함됩니다.
- 제한 뷰는 기반 데이터셋의 행을 세분화된 접근 정책으로 필터링합니다.
- 객체 보안 정책은 객체 집합에서 읽을 수 있는 객체 인스턴스를 결정합니다.
- 속성 보안 정책은 읽을 수 있는 객체 속성값을 결정합니다.
플랫폼은 사용자 특성과 그룹 소속 등을 정책 조건과 비교해 허용된 값만 반환합니다. 이렇게 반환된 평범한 값에는 원래의 행 또는 열 필터를 후속 코드가 자동으로 다시 적용할 수 있는 정책이 붙어 있지 않습니다. 원본에서 읽을 수 없던 값을 읽게 허용하는 것은 아니지만, 읽은 값의 후속 사용까지 같은 필터가 통제하는 것도 아닙니다.
읽기 정책이 따라가지 않는 경로
| 경로 | 적용되는 접근 판단과 후속 경계 |
|---|---|
| 함수 반환값 | 함수는 실행 사용자의 권한으로 허용된 객체를 읽습니다. 그 결과를 계산해 반환한 값은 원래 읽기 정책에 묶인 객체가 아니므로, 값을 받은 소비자는 전달된 결과를 그대로 사용합니다. |
| 액션 편집 | 원본 객체를 읽을 때 원본 정책이 적용됩니다. 다른 객체 유형에 쓸 때에는 쓰기 대상의 통제가 적용되고, 원본 행 정책이 자동 복제되지는 않습니다. |
| AIP Logic 도구 호출 | 온톨로지 데이터를 모델 맥락에 넣을 때 실행 사용자의 읽기 권한을 따릅니다. 맥락에 들어간 값의 요약이나 모델 출력에 원본 행 정책이 자동으로 남지는 않습니다. |
| OSDK 응답 | 실행 사용자가 읽을 수 있는 페이로드를 반환합니다. 클라이언트 애플리케이션이 렌더링, 로깅, 변환이나 전달을 할 때 그 페이로드가 원본 정책을 자동 집행하지는 않습니다. |
| Pipeline Builder의 온톨로지 출력 | 목적지 객체 유형의 접근 통제를 적용합니다. 입력 쪽 제한 뷰의 정책이 출력 객체에 자동 전파된다고 보지 않습니다. |
| 쓰기 반영(Writeback) | 제한 뷰를 기반으로 한 객체에 편집을 적용하더라도 쓰기 대상의 통제가 적용됩니다. |
| 내보내기와 다운로드 | Quiver, Contour, Workshop 등에서 플랫폼 밖으로 나온 파일에 원본의 행 또는 열 정책이 계속 적용되지는 않습니다. |
Workshop에서 속성 옆에 표시하는 보안 표지 아이콘은 설정된 요건을 알려 주는 UI입니다. 아이콘을 숨기거나 보여 주는 설정이 접근 정책을 켜고 끄는 것은 아닙니다.
보호 목적에 맞게 조합
읽기 시점에 사용자별 행을 구분하는 목적이라면 제한 뷰나 객체 또는 속성 보안 정책을 사용합니다. Foundry 안에서 데이터가 파생되어도 같은 접근 자격을 유지해야 한다면 보안 표지, 조직과 해당 데이터 분류를 적용합니다. 두 목적이 모두 필요하면 두 종류를 조합합니다.
예를 들어 보안 표지를 붙인 기반 데이터셋 위에 제한 뷰를 만들면, 원본과 파생 데이터의 자격 조건을 유지하면서 읽는 행을 구분할 수 있습니다. 같은 원본을 사용하는 다른 제한 뷰나 원본 직접 접근 경로도 함께 검토해야 합니다. 제한 뷰의 행 필터가 있다는 이유만으로 기반 데이터의 보안 표지를 제거하면, 파생 관계에 유지되던 보호 요건을 없애는 변경이 됩니다.
제한 뷰는 일반적인 변환이나 새 데이터셋을 만드는 배치 작업의 입력으로 사용할 수 없습니다. 그렇더라도 허용된 값을 읽어 함수, 액션이나 애플리케이션 결과에 사용하는 경로가 있으므로, 이 제약을 읽은 데이터의 후속 사용 금지와 동일하게 보지 않습니다.
플랫폼 밖의 데이터
Foundry가 관리하는 파생 리소스의 접근 요건과, 외부 시스템으로 전달된 평문 사본의 보호는 구분합니다. 보안 표지나 CBAC만으로 플랫폼 밖 파일의 모든 후속 열람을 계속 제어한다고 보장할 수는 없습니다.
다운로드 권한, 사유 확인 단계, 감사 로그와 데이터 최소화를 함께 적용하고, 자동 내보내기, 외부 시스템 호출과 웹훅의 통제도 검토해야 합니다. 클립보드 복사, 스크린샷과 인쇄도 데이터 반출 경로이므로 다운로드 버튼 제한만으로 모든 반출을 막을 수는 없습니다. Cipher로 암호화된 값을 암호화 상태로 내보내는 경우에는 평문 사본과 다른 보호 성격을 가지지만, 허용된 복호화 후의 값은 그에 맞게 취급해야 합니다.
자주 혼동하는 조건
제한 뷰가 읽기 전용이면 후속 데이터도 안전한가
읽기 전용이라는 성격은 제한 뷰의 스키마와 열을 변경하지 못하게 하는 무결성 조건입니다. 사용자가 읽을 수 있었던 행에 지속적인 기밀성 정책을 붙이는 기능은 아닙니다.
애플리케이션이 사용자 권한을 따르면 원본 정책이 계속 남는가
사용자 권한을 따르는 애플리케이션은 허용되지 않은 원본 값을 읽지 못합니다. 그 보장은 원본 접근에 관한 것이며, 읽은 값을 이후 다른 맥락에 전달할 때에도 같은 원본 정책이 자동으로 유지된다는 보장은 아닙니다.
프로젝트를 나누면 파생 결과도 원본 역할로 보호되는가
프로젝트는 역할 부여의 기본 단위입니다. 파생 결과가 다른 프로젝트에 있으면 그 프로젝트의 역할이 적용됩니다. 프로젝트를 넘어 유지해야 하는 자격은 전파되는 강제적 접근 통제로 구성하고, CBAC 프로젝트 분류처럼 전파되지 않는 조건은 별도로 확인합니다.