2023.08.29 - [버블 개발/중급] - 104. Data API & Privacy rule (중급) : 버블의 데이터 API 활성화, 데이터 보호규칙 설정
이 섹션에서는 Workflow API와 관련된 보안을 다룹니다.
- Bubble Workflow API에 대한 전반적인 내용을 자세히 알아보려면 아래 문서를 확인하세요
Workflow API & Privacy Rule (중급) : 워크플로 API 활성화, privacy rule 무시 설정 > 바로가기
Bubble API 소개 (중급) : 버블 Data API, 버블 Workflow API, 버블 Swagger 설정, FAQ > 바로가기
- Workflow API를 사용하면 외부 앱과 시스템이 Bubble 앱 내에서 특정 워크플로를 트리거할 수 있습니다.
- Bubble은 외부에서 앱의 Action 또는 이벤트 시퀀스를 시작할 수 있게 Endpoint 세트를 제공합니다.
- 당연히, 외부 시스템이 앱의 워크플로를 활성화하기 위해 열면, 잠재적인 취약점이 발생할 수 있으므로 올바르게 사용하는 방법을 배우는 것이 중요합니다.
이 문서에서는 안전한 API 워크플로를 설정하는 방법을 살펴보겠습니다.
(1) Workflow API 보안의 기본 원칙
1. 최소 권한의 원칙
보안 글 시리즈의 다양한 섹션에서 설명한 것처럼 Workflow API를 사용할 때 최소 권한 원칙은 여전히 중요합니다. 이 부분에서는 앱 외부에서 접근할 수 있는 워크플로를 설정할 때 이 원칙을 준수할 수 있는 방법과 전략을 자세히 살펴보겠습니다.
- 은행에서는 모든 직원이 금고 열쇠를 갖고 있는 것은 아닙니다. 창구 직원은 금전함에 접근할 수 있지만 대규모 전신 송금을 승인할 권한은 없습니다. 반대로, 은행 관리자는 해당 권한을 가질 수 있지만 반드시 모든 단일 계좌접근 권한을 가질 필요는 없습니다.
2. Authentication & Authorization(인증과 허가)
보안 글 시리즈를 순서대로 읽으면 Authentication and Authorization(인증과 허가)에 대해 광범위하게 이야기했다는 것을 기억할 것입니다.
- 인증(Authentication)은 클라이언트가 누구인지 식별하고 허가 및 권한부여(Authorization)는 클라이언트가 액세스할 수 있는 대상을 결정합니다.
- 지난번 글 [Data API]를 통해 우리는 기본적으로 데이터베이스가 무엇인지 탐구했습니다. - 특정 사용자가 접근할 수 있는 데이터 Type, 필드 및 작업들
- Workflow API는 데이터를 보호하는 대신 워크플로를 보호한다는 점을 제외하면 기본적으로 동일합니다.
보안을 계획할 때 우리는 여전히 동일한 사고 방식을 사용할 것입니다.
앱에서 워크플로를 트리거하려는 모든 클라이언트는 자신이 누구인지, 무엇에 접근할 수 있는지 확인하는 두 단계를 거쳐야 합니다.
(2) Authentication (인증)
API 워크플로가 생성되면 Bubble은 이를 트리거할 다음과 같은 고유한 엔드포인트를 자동으로 생성합니다.
https://my-bubble-application.bubbleapps.io/version-test/api/1.1/wf/my-workflow
- 워크플로에 인증이 필요하지 않은 경우 이 URL을 아는 것만으로도 모든 행위자(악의적이든 아니든)가 원하는 만큼 워크플로를 트리거할 수 있습니다.
1. 쉬운 접속방식때문에 주의해야 할 점
먼저 해당 접근 방식에 주의해야 하는 몇 가지 이유에 대해 이야기해 보겠습니다.
- API가 반복적으로 트리거되면 워크로드 소비가 증가할 수 있습니다.
*워크로드 (작업량): 앱을 계속 실행하기 위해 Bubble이 수행하는 총작업량을 구성하는 12가지 활동 유형을 측정한 것입니다. 이는 Bubble 가격 책정 계획의 핵심 요소입니다.
- 완전히 시스템을 닫지 않고 계속 실행되게 방치한 경우, Bubble에는 앱이 너무 많은 서버 리소스를 소비하지 않도록 보호 장치가 마련되어 있습니다. 이로 인해 앱 속도가 느려지거나 완전히 멈출 수도 있습니다.
- API 워크플로를 실행하면 잠재적으로 데이터베이스에 많은 변경이 발생할 수 있습니다.
- 인증(Authentication)을 요구하면 해당 워크플로의 Privacy rule 및 조건 외에 잠재적인 보호 장치가 하나 더 추가됩니다(이 점에 대해서는 문서 뒷부분에서 다시 설명하겠습니다.)
- API 워크플로를 원하는 대로 자유롭게 설정할 수 있지만 일반적으로 이를 실행하려면 항상 인증(Authentication)을 요구하는 것이 좋습니다.
2. 3가지 접근 레벨
데이터 API와 마찬가지로 API 워크플로의 액세스 수준은 세 가지 범주로 나눌 수 있습니다.
- 어떤 클라이언트도 API 워크플로에 액세스할 수 없음 (워크플로 API가 비활성화되거나 모든 API 워크플로가 노출되지 않음)
- 일부 클라이언트는 선택한 API 워크플로에 액세스 할 수 있음 (워크플로 API가 활성화되어 있지만 인증이 필요함)
- 누구나 액세스할 수 있음 (워크플로 API가 활성화되어 있으며, 인증이 필요한 API 워크플로가 없음)
다음으로 3가지 접근 레벨에 대해 자세히 알아보겠습니다.
3. 어떤 클라이언트도 API 워크플로에 액세스 할 수 없음
첫 번째 시나리오는 자격 증명이 무엇이든 어떤 클라이언트도 API 워크플로에 전혀 액세스 할 수 없다는 것입니다.
이를 수행하는 방법에는 다음에 나오는 두 가지가 있습니다.
1) 워크플로 API 비활성화
- 첫 번째 방법은 Settings > API 에서 Workflow API를 완전히 비활성화하는 것입니다.
- 이렇게 하면 Workflow API 엔드포인트가 전혀 노출되지 않으며 앱 외부에서 아무것도 트리거 될 수 없습니다. 그러나 이는 Bubble의 백엔드 편집기가 완전히 비활성화된다는 의미이기도 합니다.
- 즉, 내부 Backend API 워크플로를 설정할 수 없음을 의미합니다.
2) 개별 워크플로 비활성화
두 번째 옵션은 워크플로 API를 활성화한 상태로 유지하면서 생성하는 모든 API 워크플로를 노출되지 않도록 설정하는 것입니다. 즉, API 워크플로는 앱 내부에서 트리거될 수 있지만 외부에서 트리거할 수 있는 엔드포인트가 없습니다.
- Expose as a public API workflow (공개 API 워크플로로 노출) 박스를 비워두면 외부 앱 및 시스템에서 개별 API 워크플로의 접근을 차단할 수 있습니다.
- 이 방법을 사용하면 백엔드 편집기와 모든 기능에 액세스 할 수 있지만, 각 개별 API 워크플로의 노출 설정에 주의해야 합니다.
4. 일부 클라이언트는 선택한 API 워크플로에 액세스할 수 있음
두 번째 옵션은 인증(Authentication)을 요구하고 선택한 API 워크플로가 앱 외부에서 트리거 되도록 여는 것입니다.
1) 인증(Authentication)
- API 워크플로에 대한 접근 권한을 부여하기 위해 클라이언트를 인증하는 것은 몇 가지 다른 방법으로 수행할 수 있습니다. 아래 글에서 이에 대해 자세히 설명합니다.
Authentication (중급) : API 인증 bearer token, 인증 없이 접속, 사용자 인증, 관리자 인증 > 바로가기
2) 선택한 API 워크플로 노출
인증을 설정한 후에는 노출하려는 API 워크플로 설정을 진행할 수 있습니다.
- API 워크플로는 생성 시 자동으로 노출되도록 설정되어 있습니다. 이 단계에서는 노출하고 싶지 않은 워크플로를 비활성화하는 것이지 그 반대는 아닙니다. (위의 3-(2)와 같은 기능)
- 노출을 원하지 않는 API 워크플로를 비활성화하려면 Expose as a public API workflow (공개 API 워크플로로 노출 설정)을 선택 취소하세요. 이렇게 하면 해당 워크플로의 엔드포인트가 완전히 제거되어 인증에 관계없이 트리거가 불가능해집니다.
이렇게 하면 선택된 클라이언트만 API 워크플로를 실행할 수 있으며, 클라이언트가 누구인지에 관계없이 선택된 워크플로만 실행할 수 있습니다.
5. 누구나 접근할 수 있음 (권장하지 않음)
마지막 옵션은 전혀 인증할 필요 없이 누구든지 트리거할 수 있도록 API 워크플로를 여는 것입니다. 일반적으로 이 방법은 오용의 위험이 있으므로 권장하지 않습니다.
- 인증 없이 트리거 될 API 워크플로를 열려면 위에 표시된 두 상자를 선택하세요. 선택적으로 마지막 상자( 워크플로 실행 시 개인 정보 보호 규칙 무시)를 선택하여 데이터에 대한 최대한 광범위한 액세스 권한을 부여할 수도 있습니다.
(3) Authorization (허가 및 권한 부여)
데이터 API를 사용하면 허가 및 권한부여(authorization)는 일반적으로 클라이언트가 보고 변경할 수 있는 데이터와 연결됩니다.
- Workflow API의 허가 및 권한부여(authorization)는 그림이 약간 더 복잡해집니다.
- 결과적으로, 우리가 workflow를 직접 다루기 때문에 각 개별 클라이언트에 대한 인증을 세부적으로 조정할 수 있는 두 가지 방법이 추가로 있습니다.
1. workflow API의 추가적인 허가(Authorization) 방법 두 가지
- Data ( Privacy rule로 보호될 수 있음 )
- Condition (워크플로 또는 해당 워크플로 내의 개별 작업 단계에 대한 추가 제한을 설정할 수 있음)
아래에는 그림으로 전체 workflow API 인증과 허가 그리고 추가적인 허가방법에 대해 설명합니다.
API 워크플로는 위에 설명된 것처럼 여러 단계의 허가(autorization)를 거칠 수 있습니다.
위의 도식 그림에서, 우리는 Workflow API Request가 허가를 위해 거칠 수 있는 잠재적인 경로를 볼 수 있습니다.
1) 허가 및 권한 부여 1 (Authorization1)
- 먼저 Bubble은 클라이언트가 누구인지(인증: Authentication) 확인한 다음 클라이언트가 해당 워크플로를 실행할 수 있는지 여부를 확인합니다. 허가(Authorization1)
2) 허가 및 권한 부여 2 (Authorization2)
- 그런 다음 그림과 같이 두 가지 권한 부여 단계(권한 부여 2로 설명됨)를 더 도입할 수 있습니다.
- Condition(조건)은 클라이언트 가 전체 워크플로 또는 해당 작업 중 하나 이상을 실행하는 것을 중지할 수 있으며, Privacy rule(개인 정보 보호 규칙)은 클라이언트가 수행할 데이터를 찾는 접근을 제한할 수 있습니다.
그림의 내용이 워크플로우 편집기에서 어떻게 보이는지 살펴보겠습니다.
- API 워크플로를 실행하려면 인증/권한 부여가 필요할 수 있습니다. (Authorization 1)
- Privacy rule에 따라 일부 또는 전체 기록이 검색되지 않도록 보호하므로 변경 사항의 결과 가 제한될 수 있습니다. (Authorization 2)
- Only when 조건식은 인증된 경우에도 조건(Condition)에 따라 클라이언트가 워크플로를 실행하지 못하도록 금지할 수 있습니다. (Authorization 1)
2. 데이터(Privacy rule)
개인 정보 보호 규칙에 대해 잘 모르는 경우 아래 문서를 읽고 해당 규칙의 작동 방식을 이해하는 것이 좋습니다.
Data API & Privacy rule (중급) : 버블의 데이터 API 활성화, 데이터 보호규칙 설정 > 바로가기
Bubble Dynamic Expressions (중급) : 버블 동적 표현식, 버블의 핵심 표현식 알아보기, 특징 및 설정 방법 > 바로가기
- 사용하려는 인증 방법을 설정한 후에는 해당 클라이언트가 해당 워크플로의 작업 단계 내에서 데이터에 접근할 수 있도록 권한을 부여해야 합니다.
- 보안을 계획할 때 이러한 이해를 이해하는 것이 중요합니다. 그렇지 않으면 예기치 않은 결과가 발생할 수 있습니다.
위의 설명을 예시로 살펴보겠습니다.
1) 사용자 목록에 일부 정보 추가
사용자가 100명인 Bubble 앱이 있다고 가정해 보겠습니다. Bubble API를 통해 외부 시스템으로 작업하는 방법을 탐색하기 시작하면서 모든 사용자에게 일부 데이터를 추가해야 한다는 것을 깨달았습니다. 즉 우리는 모든 항목을 변경하고 싶습니다.
- 우리는 해당 작업을 수행하기 위해 API 워크플로를 설정하기로 결정하고 외부 앱에서 이 작업이 트리거 될 수 있도록 외부 액세스를 허용합니다.
이 API 워크플로의 경우 원칙적으로 두 가지 권한 부여(Authorizatin) 과정을 거칩니다.
- 첫 번째는 클라이언트가 워크플로를 실행할 수 있는 권한을 부여받는 것입니다.
- 그런 다음, 두 번째는 검색할 수 있는 사용자를 선택합니다.
다시 말해, 이 경우에는 한번만 인증하지만 원칙적으로 두 차례의 허가(Authorization)를 거치게 됩니다.
- 클라이언트가 이 워크플로를 실행할 수 있는지 허가
- 클라이언트가 이러한 사용자를 검색할 수 있는지 허가
이 예시를 통해 이것이 때때로 예상치 못한 결과를 생성할 수 있는 이유를 알 수 있습니다.
클라이언트가 워크플로를 실행할 수 있는 접속 권한을 갖고 있지만 실제로 데이터베이스의 모든 사용자를 검색하지 못할 수도 있습니다.
이유가 무엇일까요?
- 해당 데이터는 Privacy rule에 의해 보호되고 클라이언트는 모든 데이터를 다운로드하는 데 필요한 자격 증명과 일치하지 않기 때문입니다.
- 이 경우 예상치 못한 결과는 Privacy rule에 따라 클라이언트가 사용자를 찾을 수 없도록 하여 사용자 중 일부만 변경되거나 전혀 변경되지 않을 수 있다는 것입니다.
데이터 API를 사용하면 API를 통한 수정, API를 통한 생성 등과 같은 특정 Privacy rule을 설정할 수 있습니다. 참고로, 이러한 설정은 특별히 Data API에 적용되고 해당 작업을 수행하는 API 워크플로의 기능에는 영향을 미치지 않습니다.
2) Privacy rule 무시
데이터에 대해 가능한 한 가장 광범위한 액세스 수준을 제공하려는 경우 Privacy rule을 완전히 무시하도록 API 워크플로를 설정할 수 있습니다.
- 다시 한 번 말씀드리지만, 이 방법을 사용하면 설정된 Privacy rule에 관계없이 데이터베이스의 모든 데이터에 무료로 액세스 할 수 있으므로 일반적으로 이 방법을 사용하지 않도록 주의합니다.
- 그럼에도 불구하고 이것이 유용한 시나리오가 많이 있습니다. 자신의 앱 서비스의 성격과 목적을 확인하여 적용을 고려하십시오
3. Conditions (조건식)
- 조건식에 익숙하지 않은 경우 아래 문서를 읽고 조건식이 어떻게 작동하는지 이해하는 것이 좋습니다.
Bubble Conditons (중급) : 버블 조건식, 동적 표현식을 트리거하는 조건 > 바로가기
Bubble Dynamic Expressions (중급) : 버블 동적 표현식, 버블의 핵심 표현식 알아보기, 특징 및 설정 방법 > 바로가기
허가 및 권한부여(Authorization)의 두 번째 단계에서는 조건식 구현에 대해 더 신중하게 생각하게 될 수 있습니다.
- 워크플로 자체 또는 해당 작업 단계에 조건식을 추가할 수 있습니다. Bubble은 워크플로를 실행하려는 클라이언트에 대해 조건을 확인하고 또 다른 인증 계층을 추가합니다.
- Privacy rule도 조건에 영향을 미칠 수 있다는 점을 명심하세요.
- 예를 들어 조건이 데이터베이스 검색에 의존하여 유효성을 검사하는 경우 결과가 Privacy rule에 의해 제한되면 예상한 결과를 얻지 못할 수 있습니다.
- 위의 예시에서는 현재 사용자(API 워크플로를 실행하는 인증된 클라이언트)의 Admin 필드가 yes로 설정되어 있는지 확인하는 조건을 추가하여 API 워크플로의 작업 중 하나를 추가로 제한했습니다. (이것이 아니 오를 반환 하면 단계가 실행되지 않습니다.)
(4) Workflow API 보안 체크리스트
- '최소 권한의 원칙'을 염두에 두세요
- 접근 인증(Authentication)이 있는 사람 결정(데이터 API에 액세스 할 수 있는 사람을 결정)합니다.
- 모든 사람 차단
- 선택된 클라이언트 및 워크플로우만 승인
- 모든 클라이언트 승인
- 접근할 수 있는 항목 결정(Authirization , 노출하려는 API 워크플로만 활성화하세요
- Privacy rule을 사용하여 워크플로에서 찾을 수 있는 데이터 제어
- Conditions(조건식)을 사용하여 보다 세분화된 승인을 적용
