이 섹션에서는 데이터 API와 관련된 보안을 다룹니다.
- Bubble Data API에 대한 전반적인 내용을 자세히 알아보려면 아래 문서를 확인하세요
Data API & Privacy rule (중급) : 버블의 데이터 API 활성화, 데이터 보호규칙 설정 > 바로가기
Bubble API 소개 (중급) : 버블 Data API, 버블 Workflow API, 버블 Swagger 설정, FAQ > 바로가기
- 데이터 API를 사용하면 외부 앱 및 시스템이 Bubble 앱에 저장된 데이터와 상호 작용할 수 있습니다. Bubble은 데이터 생성, 읽기, 업데이트 및 삭제를 위한 endpoint를 제공합니다.
- 외부 시스템에게 Bubble 앱 데이터베이스에 대한 접속 권한을 부여하면 잠재적인 취약점이 발생할 수 있으므로 이를 올바르게 사용하는 방법을 배우는 것이 중요합니다.
(1) Data API 보안의 기본 원칙
1. 최소 권한의 원칙
보안 관련 글 시리즈에서 여러 번 살펴본 것처럼 최소 권한 원칙은 데이터 API에도 강력하게 적용됩니다. 이제 데이터 API를 설정할 때 이 원칙을 준수하기 위해 계획하고 실행하는 방법을 살펴보겠습니다.
- 은행에서는 모든 직원이 금고의 열쇠를 갖고 있는 것이 아닙니다. 창구 직원은 계좌 인출 권한에 접근할 수 있지만 대규모 전신 송금을 승인할 권한은 없습니다.
- 반대로, 은행 관리자는 해당 권한을 가질 수 있지만 반드시 모든 금고에 접근할 수는 없습니다.
- 즉 최소권한의 원칙으로 모든 API에 필요한 만큼의 권한만 주어지는게 잠재적 사고를 방지할 수 있는 기본 원칙입니다.
2. 인증과 허가(Authentication and authorization)의 의미
1) 정의
API 소개 글에서 인증(Authentication)과 허가 및권한부여(authorization)라는 두 가지 형제 개념을 살펴보았습니다. 인증(Authentication)은 클라이언트가 누구인지 식별하고 허가(권한부여)(authorization)은 클라이언트가 접속할 수 있는 대상을 결정합니다.
2) 예시1
이 논리가 구성되는 방식은 실제 생활과 다르지 않습니다.
- 누군가를 현관문으로 들여보내기 전에, 그 사람이 누구인지 알고 싶을 것입니다.
- 이런 방식으로 그들은 인증(Authentication)을 받고 (당신은 그들의 얼굴을 인식합니다), 이를 통해 당신은 그들이 접근할 수 있는 것을 허가 및 권한부여(authorization) 할 수 있습니다.(집에 들어갑니다)
3) 예시 2
수많은 실제 시나리오에 동일한 인증식별 및 허가 패턴이 적용됩니다.
- 공항에서: 승객은 누구입니까? 어떤 비행기를 이용할 수 있습니까?
- 영화관에서: 그 사람이 티켓을 가지고 있나요? 어떤 영화를 보나요?
- 은행에서: 고객은 누구입니까? 고객이 접근할 수 있는 은행 계좌는 무엇입니까?
4) Data API 사용 시
실제 시나리오에서 이를 강조하는 이유는 보안 계획에 대한 인증/권한 부여 사고방식을 강조하기 위한 것입니다. 데이터 API에 대한 보안을 계획할 때 정확히 같은 방식으로 질문할 수 있습니다.
- 내 앱의 데이터베이스에 접속하려는 클라이언트는 누구입니까?
- 이 클라이언트는 무엇에 접속할 수 있어야 합니까?
5) 활용 - [최소 권한의 원칙] + [승인, 권한부여의 원칙]
이러한 승인, 권한부여의 사고방식과 최소 권한의 원칙을 결합하면 다음과 같은 몇 가지 매우 유용한 경험상의 안전 법칙이 있습니다.
- 내 앱의 데이터베이스에 접속하려는 클라이언트는 누구입니까? 최소 권한의 원칙을 적용하려면 알아야 합니다.
- 이 클라이언트는 무엇에 접속할 수 있어야 합니까? 최소 권한의 원칙에 따라 – 필요한 만큼만 알고 1도 더 이상은 안 됩니다.
다음으로 이러한 원칙을 확립한 후 앱을 개발할 때 실제로 이것이 무엇을 의미하는지 살펴보겠습니다.
(2) 인증(Authentication)
보안 거래의 첫 번째 단계는 고객이 누구인지 아는 것입니다.
데이터 API의 경우 이는 세 가지 범주로 나눌 수 있습니다.
- 아무도 액세스 할 수 없음 (데이터 API가 비활성화된 상태)
- 일부 클라이언트에 액세스 권한 부여 (데이터 API가 활성화되어 있지만 인증이 필요함)
- 누구나 액세스할 수 있음 (데이터 API가 활성화되어 있으며 인증이 필요하지 않음)
1. 아무도 액세스 할 수 없음
앱의 데이터 API에 활성화를 하기 전에 누가 액세스 권한을 가져야 하는지 여부를 결정해야 합니다.
- 데이터 API는 기본적으로 비활성화되어 있지만 앱의 Settings > API섹션에서 Enable Data API를 선택하여 활성화할 수 있습니다.
- 앱에서 데이터베이스에 액세스 하는 데 외부 앱이나 시스템이 필요하지 않은 경우 해당 확인란을 선택 해제된 상태로 안전하게 유지할 수 있습니다.
- 이렇게 하면 데이터 API의 연결이 완전히 끊어지고 다른 보안 조치가 필요하지 않습니다.
2. 일부 클라이언트에게 액세스 권한 부여
액세스 범위의 두 번째 수준은 하나 이상의 클라이언트에 액세스 권한을 부여하는 것이지만 모든 사람에게 액세스 권한을 부여하는 것은 아닙니다.
- 여기에는 데이터 API가 활성화되고 앱의 데이터베이스에 액세스 하려는 모든 시스템을 인증("ID 확인")해야 함을 의미합니다.
- 모든 사람에게 액세스 권한을 부여하지 않고 외부 앱이나 시스템을 인증하는 방법에는 두 가지가 있습니다.
각 항목을 설정하는 방법을 알아보려면 아래 나열된 문서 링크를 따르세요.
1) 사용자로 인증
기본적으로 일반 사용자와 동일한 방식으로 앱에 "로그인"하는 것을 의미합니다. 즉, 개인 정보 보호 규칙을 적용하여 해당 사용자가 액세스 할 수 있는 항목을 제어할 수 있습니다.
- 이는 해당 사용자가 데이터베이스에서 수행할 수 있는 작업과 수행할 수 없는 작업에 대해 높은 수준의 제어를 제공하는 액세스 수준입니다.
- 이 인증 방법을 사용하면 일반적으로 누가 무엇에 액세스할 수 있는지에 대한 규칙을 계속 설정하게 됩니다. 즉, 권한을 부여하는 것입니다.
Authentication (중급) : API 인증 bearer token, (2) - 2. 사용자로 인증 > 바로가기
2) 관리자로 인증
Bubble에 내장된 API 토큰 시스템을 사용하여 액세스 권한을 부여하는 것을 의미합니다. 이렇게 하면 자동으로 전체 관리자 액세스 권한이 부여됩니다.
- 즉, 앱 개발자와 동일한 액세스 수준을 의미합니다. (앱에서 설정한 관리자 역할과 혼동하지 마세요)
- 이 액세스 수준은 앱의 모든 데이터를 읽고, 수정하고, 삭제할 수 있는 광범위한 권한을 부여합니다.
- 암시적으로 신뢰하는 외부 앱이나 시스템에서만 사용되도록 하세요
Authentication (중급) : API 인증 bearer token, (2) - 3. 관리자로 인증 > 바로가기
3. 누구나 접근할 수 있음
이 옵션에서는 인증 단계를 모두 무시합니다. 문은 열려 있고 누구나 들어갈 수 있습니다.
누가 문을 통과하는지 확인하지 않기 때문에 각 방문자가 무엇에 액세스해야 하는지 결정할 수 없다는 로직을 따릅니다.
- 모든 사람은 동일하게 대우받습니다.
- 이 방법은 데이터베이스에 대한 무료 공개 액세스를 제공하기로 결정한 경우에만 사용해야 합니다. 이는 보안뿐만 아니라 앱이 소비하는 워크로드의 양에도 영향을 미칠 수 있다는 점을 명심하세요. API 요청은 서버 리소스를 소비하여 총 워크로드에 추가되기 때문입니다.
- 모든 사람에게 액세스를 제공하도록 데이터 API를 설정하는 방법을 알아보려면 아래 문서를 참조하세요.
Authentication (중급) : API 인증 bearer token, (2) - 1. 인증 없이 접속 > 바로가기
(3) 허가 및 권한 부여(Authorization)
앞서 표현한 은행 비유로 돌아가자면: 은행에 고객으로 등록하는 사람은 자신의 계좌에 접근할 수 있어야 하지만 한 개인이 자신의 계좌가 아닌 모든 계좌에 접근할 수 있다면 이상하다고 생각할 것입니다.
- 이처럼 앱을 사용하도록 인증된 사람들에게도 모든 데이터를 공유하고 싶지 않다는 논리가 동일하게 적용됩니다.
- 우리는 인증(클라이언트가 누구인지)을 처리했으며 이제 해당 클라이언트에 대한 허가*(클라이언트가 액세스 할 수 있는 대상)을 결정하는 방법에 대해 알아볼 시간입니다.
이는 다음의 두 가지 방법으로 수행됩니다.
1. 데이터 Type 활성화
데이터를 보호하는 첫 번째 단계는 노출하려는 데이터 Type만 활성화하는 것입니다.
다음 사항에 유의하세요
- Settings > API에서, 당신이 사용 가능으로 활성화하지 않은 데이터 Type은 사용자 인증방법에 관계없이 데이터 API에서 사용할 수 없습니다.
- 사용 가능으로 활성화된 데이터 Type은 노출되나, 클라이언트 인증과 함께 Privacy rule을 준수합니다.
- Settings > API 에서, 다음 사진과 같이 데이터 API를 활성화하면 표시하려는 데이터 Type 목록이 표시됩니다.
- 활성화되지 않은 (선택 해제된) 데이터 Type은 누구도 접근할 수 없습니다.
- 위의 예시에는 다른 앱과 공유하려는 Product 데이터 유형이 있습니다.
- ‘최소 권한 원칙’에 따라 해당 항목만 활성화하고 다른 모든 데이터 Type은 선택하지 않은 상태로 유지합니다.
- 이 설정은 가장 중요한 권한 부여, 즉 모든 클라이언트가 액세스 할 수 있는 데이터 Type을 관리합니다.
다음 단계에서는 Privacy Rule을 살펴보겠습니다. 이 규칙은 세밀한 제어 기능을 제공합니다.
2. Privacy Rule (개인 정보 보호 규칙)
노출하려는 데이터 Type을 활성화한 후에는 일반적으로 Privacy Rule을 사용하여 해당 데이터 Type의 어떤 필드에 액세스할 수 있는지, 어떤 종류의 작업을 수행할 수 있는지 제어하는 것이 좋습니다.
- 일반 앱의 보안과 마찬가지로 Privacy Rule은 사용자별로 설정됩니다.
즉, 사용자의 인증에 따라 해당 사용자가 수행할 수 있는 액세스 수준이 결정됩니다.
액세스 수준별 할 수 있는 활동 예시
- 검색으로 데이터 찾기 권한
- 데이터의 노출할 필드와 업로드된 파일
- 데이터를 Create, Edit, Delete 할 수 있는 권한
API에 노출된 데이터 Type 대한 Privacy rule을 설정하는 방법에 대한 자세한 지침은 아래 문서를 확인하세요.
Data API & Privacy rule (중급) : 버블의 데이터 API 활성화, 데이터 보호규칙 설정 > 바로가기
(4) Data API 보안 체크리스트
위의 방법을 염두에 두고, 데이터 API를 보호하는 또 다른 도구를 살펴보겠습니다.
- 최소 권한의 원칙을 염두에 두세요
- 인증(Authentication) : 누가 접속 가능한지 결정하세요. API에 액세스할 수 있는 사람을 결정합니다.
- 아무도 접속 못 함
- 선택된 클라이언트 (사용자, 관리자)
- 모든 클라이언트
- 허가 (Authorization) : 어떤 데이터에 접속 가능한지 결정하세요
- 노출하려는 데이터 Type만 활성화합니다.
- 필드 및 편집 권한을 세밀하게 제어하려면 Privacy rule을 사용하세요
