이 섹션에서는 앱의 개인정보 보호 및 보안에 관한 정책을 수립하기 위해 작업할 수 있는 방법을 살펴봅니다.
(1) 보안 계획의 의사결정
앱에서 구현하기로 선택한 모든 보안 및 개인 정보 보호 조치는 앱 구현자의 의사결정으로 시작되며 이러한 의사결정은 두 가지 관점에서 이루어집니다.
1. 필수 보안과 개인 정보 보호
- 이것은 사용자가 거주하는 국가, 지역의 법규정을 준수하기 위해 필요한 보안 및 개인 정보 보호를 하는 수준입니다.
- 이는 앱이 사용자 데이터를 수집, 저장, 처리 및 공유하는 방법을 규정하는 법적 요구 사항입니다.
2. 선택적 보안과 개인 정보 보호
개발자가 앱 소유자로서 사용자의 개인 정보를 더욱 보호하기 위한 모든 조치입니다. 이는 종종 다음을 기반으로 합니다.
- 사용자의 입장에서 생각해 보기
- 커뮤니케이션의 마케팅적 이용 (예: 엄격한 개인정보 보호를 마케팅 포인트로 사용)
- 나만의 전력과 투명성
- 위의 사항과 관련하여, 전체적으로 앱이 어떻게 작동하는지 기획이 있어야 합니다.
- 이렇게 하면 어떤 데이터를 비공개로 유지해야 하는지 알 수 있으므로 개발 프로세스가 더 원활해질 뿐만 아니라 앱 정책을 완전히 숙지하게 되므로 사용자와의 명확한 의사소통이 가능해집니다.
1) 사용자의 입장에서 생각해 보기
개발자는 앱을 계획할 때 사용자가 일정 기대치를 갖고 앱을 방문하게 돕다는 사실을 염두에 두어야 합니다.
- 기본적으로 많은 앱 사용자는 자신의 데이터를 완전히 공유하기로 선택하지 않았다면, 다른 사용자에게 표시되지 않고 자신만의 데이터로 유지되기를 자연스럽게 기대합니다.
- 또한 그들은 개인 정보 보호 설정을 하고, 전부는 아니지만 일부만 공유하고도 기본 서비스를 사용할 수 있을 것으로 기대할 수도 있습니다.
- 예를 들어, 소셜 미디어 애플리케이션에서 사용자는 공개 게시물의 초안이 비공개로 유지되고 게시되기 전에 다른 사람에게 표시되지 않을 것으로 기대할 수 있습니다. 피트니스 트래커의 경우에도 마찬가지입니다. 사용자는 자신의 최신 운동을 전 세계와 공유할 기회를 원할 수 있지만 모든 운동을 공유하는 것을 원치 않을 수도 있습니다.
- 앱을 구성하기 전에 사용자의 입장에서 생각해 보면 사용자의 요구를 존중하고 사용자 정보를 제어할 수 있는 기반 위에 앱을 구축할 수 있습니다. 실제 선호 사항과 우려 사항을 바탕으로 결정을 내리고 있는지 확인하기 위해 사용자 인터뷰를 실시하는 것도 고려할 수 있습니다.
사용자는 투명성을 기대합니다.
여기에는 수집되는 데이터, 수집 이유, 사용 방법에 대한 명확성이 포함됩니다. 명확한 개인 정보 보호 정책, 쉽게 접속할 수 있는 사용자 설정, 데이터 수집 관행에 대한 옵트인/아웃 옵션과 같은 기능은 이러한 기대를 충족하고 사용자 기반의 신뢰를 구축하는 데 큰 도움이 될 수 있습니다.
2) 커뮤니케이션 마케팅적 이용
마케팅적으로 보안(개인정보 보호)을 앱 브랜드의 커뮤니케이션의 일부로 만들 수 있습니다.
- 사용자에게 데이터 수집 및 저장 방식을 알리며 앱 전략을 명확하게 표시하고 데이터가 사용되는 용도를 투명하게 공개하여 의식적으로 신뢰를 구축하고 가입 문턱을 낮출 수 있습니다.
3) 자신만의 전략과 투명성
- 앱이 어떻게 작동하길 바라나요? 당신의 개인적인 기준은 무엇입니까?
- 사용자 데이터를 수집하고 공유하는 것은 본질적으로 나쁜 것은 아니지만 개발 프로세스를 시작하기 전에 신중하게 고려해야 합니다.
- 엄격한 개인정보 보호를 목표로 하고 있나요? 또는 마케팅, 분석, 사용자 패턴 이해, 수익 창출 등 다양한 목표에 이를 활용할 계획인가요?
개인정보 관리를 투명하고 책임 있게 하고 있는 한, 이들 중 어느 것도 그 자체로 부정적이거나 비윤리적이지 않습니다. 투명성이란, 사용자와의 커뮤니케이션을 통해 수집된 데이터의 종류, 사용 방법, 이유를 사용자에게 알리는 것입니다.
3. 투명성 및 문서화
사용자 데이터 관리는 필수적인 책임이므로 가볍게 여겨서는 안 됩니다.
- 이전의 두 가지 관점으로 돌아가서, 보안 및 개인 정보 보호 정책을 전달하는 방법은 법적 요구 사항과 커뮤니케이션 전략이 혼합된 것입니다.
- 앱이 법규정을 준수하려면 일부 문서가 있어야 하지만, 한편으로 커뮤니케이션을 통해서 필요한 것 이상을 공유하도록 선택할 수도 있습니다.
4. 보안에 필요한 서류들
많은 산업과 국가에 걸쳐진 개인정보 보호법은 당신이 어떻게 데이터를 보관, 처리하는지에 대한 문서적인 법률조항들이 명시되어 있습니다.
- 이 섹션에서는 앱이 실제 사용자를 수용하기 전에 준비해야 하는 몇 가지 공통 문서를 강조하겠습니다.
- 이 목록은 수많은 개인 정보 보호 및 보안 프레임워크에서 흔히 요구되는 문서 유형을 보여줍니다. 그러나 이는 절대로 모든 산업에 포괄적이지 않고, 법적 조언으로 해석되어서는 안 됩니다.
- 개발자의 산업에 맞는 법률 준수 전략을 수립하려면 전문 법률 자문을 구해야 합니다.
*일부는 북미기준임을 참고하세요
| 문서 | 설명 |
| 개인 정보 정책 | 이용자의 개인정보를 수집, 이용, 관리하는 방법을 공개하는 문서입니다. GDPR, CCPA 및 전 세계의 기타 여러 법률에서 요구합니다. |
| 서비스 이용 약관/조건 | 사용자가 앱을 사용하기 위해 준수하기로 동의한 규칙입니다. 데이터 보호 규정에 명시적으로 요구되지는 않지만 허용 가능한 사용, 분쟁 해결 및 책임 면책 조항이 자세히 설명되어 있는 경우가 많습니다. |
| 쿠키 정책 | 특히 EU 사용자의 경우 쿠키를 사용할 때 사용 중인 쿠키, 추적하는 데이터 및 사용자가 이러한 쿠키를 제어할 수 있는 방법을 설명하기 위해 쿠키 정책이 필요합니다. 개인정보 보호정책에 포함되는 경우도 있습니다. |
| 데이터 처리 계약(DPA) | 귀하를 대신하여 데이터를 처리하는 제3자 공급업체를 이용하는 경우 GDPR에 따라 귀하와 공급업체 간의 DPA가 필요합니다. 본 계약에는 데이터 보호와 관련하여 양 당사자의 책임과 의무가 명시되어 있습니다. |
| 데이터 침해 통지 계획 | 데이터 침해가 발생한 경우 사용자(및 관련 기관)에 알릴 계획입니다. 이는 일반적으로 공개 문서는 아니지만 GDPR의 핵심 요구 사항입니다. |
| 아동 개인정보 보호정책 | 웹 애플리케이션이 어린이를 대상으로 하거나 어린이의 데이터를 처리하는 경우 미국의 COPPA와 같은 규정에 따라 특정 정책이 필요할 수 있습니다 |
(2) 보안을 염두에 둔 앱 구조 설계
웹 앱 보안을 논의할 때 "개인정보 보호 설계"라는 용어를 자주 듣게 됩니다. 이는 본질적으로 데이터 보호에 대한 사전 예방적 접근 방식으로, 처음부터 개발 프로세스에 개인 정보 보호 및 데이터 보호 조치를 구축하는 것의 중요성을 강조합니다.
- 여기에는 전체 개발 단계에서 개인 정보 보호 문제와 위험을 고려하여 시스템 설계에 보안을 내재화하는 작업이 포함됩니다.
목표는 개인 정보 위험을 최소화하고 사용자 데이터를 보호하며 데이터 보호 규정을 준수하는 것입니다.
- Bubble은 빠르게 구축할 수 있는 플랫폼이지만 처음부터 보안 및 개인 정보 보호를 고려하지 않고 앱을 개발하면 작업을 다시 처음부터 추적해야 할 수도 있습니다.
- 이 가이드에서는 모범적인 사례를 설명하려고 시도하지 않는 대신, 앱 보안을 계획할 때 고려해야 할 일반적인 사항을 강조하겠습니다.
- 이러한 사항 중 일부는 앱 빌드를 시작하기 전에 Bubble 매뉴얼의 다른 섹션을 알아야 할 수도 있습니다. 개발 프로세스를 시작하기 전에 해당 시간을 투자하여 앱 보안의 기본 사항을 알아보는 것이 좋습니다.
1. 보안 요구 수준 결정
고려해야 할 첫 번째 측면은 앱 전체에 필요한 보안 수준입니다. 일부 앱은 엄격한 보안 조치가 필요하지 않을 수 있지만 다른 앱은 데이터 보호 및 개인 정보 보호에 중점을 두어야 합니다.
- 당신의 앱은 어떤 종류인가요? 공개 데이터만 데이터베이스에 저장하시겠습니까, 아니면 안전하게 비공개로 유지되어야 하는 데이터를 저장하시겠습니까?
사용자의 기대 수준을 고려하십시오
- 특정 데이터가 비공개임을 명시적으로 언급하지 않더라도 사용자는 종종 그렇다고 가정할 것입니다.
- 사용자의 입장에서 생각하고 잠재적인 사용자와 직접 대화하는 것은 사용자의 기대에 맞는 개인 정보 보호 및 보안 관련 정책을 마련하는 데 도움이 될 수 있습니다.
2. 최소 권한의 원칙
최소 권한의 원칙은 소프트웨어 개발의 기본 보안 개념이며 Bubble에서 앱을 제작할 때에도 다르지 않습니다. 아이디어는 간단합니다. 사용자에게 작업을 수행하는 데 필요한 만큼의 접근권한만 부여하고 그 이상은 부여하지 않는 것입니다.
이 원칙은 다음에 적용됩니다.
- 앱 사용자
- API 서비스 ( 인바운드 및 아웃바운드 )
- 협력사
- 개발자와 관리자들, 팀 구성원들
은행에서는 모든 직원이 금고 열쇠를 갖고 있는 것은 아닙니다. 창구 직원은 금전함에 접근할 수 있지만 대규모 전신 송금을 승인할 권한은 없습니다. 반대로, 은행 관리자는 해당 권한을 가질 수 있지만 반드시 모든 각 계좌에 접근할 필요는 없습니다.
마찬가지로 Bubble 앱에서는 다음을 확인해야 합니다.
1) 개인 정보 보호 규칙을 통한 데이터 제한
- 사용자가 자신의 역할과 관련된 데이터만 보거나 수정할 수 있도록 합니다. 일반 사용자인 경우 관리자 수준 데이터나 구성원의 데이터에 접근할 수 없어야 합니다.
2) 기능/페이지 접근 권한
- 각 사용자 역할에 필요한 기능만 표시하도록 사용자 인터페이스를 조정합니다. 예를 들어 사이트 관리자는 댓글 삭제 옵션을 볼 수 있지만 일반 사용자는 그렇지 않습니다. 로그아웃한 사용자는 특정 페이지에 접근하지 못할 수도 있습니다.
3) workflow 권한
- 필요한 사용자만 특정 워크플로, 특히 데이터를 변경할 수 있는 워크플로를 트리거할 수 있는지 확인하세요
이는 보안 계획을 안내하는 중요한 원칙입니다.
- 최소 권한 원칙을 따르면 보안을 강화할 뿐만 아니라 사용자 경험도 단순화할 수 있습니다.
- 이는 우발적인 변경을 방지하고 잠재적인 오용을 방지하는 데 도움이 됩니다.
(3) 무엇을 계획해야 할까요?
계획의 목적은 더 나은 의사결정을 내리는 데 도움이 되는 정보를 제공하는 것이라 말할 수 있습니다.
- 개발자나 고객이 앱에 대한 어떤 아이디어를 갖고 있는 경우, 이는 일반적으로 개념적 수준에 있습니다. 많은 경우 이는 내가 해결하고 싶은 문제가 무엇인지, 어떻게 해결하고 싶은지에 대한 생각일 것입니다.
- 그러므로, 기본적으로 문제와 해결책은 앱이 탄생한 이유를 구성한다고 말할 수 있습니다.
그런 다음 앉아서 개발을 시작합니다.
- 훌륭한 호텔을 구상하는 것이 건축 계획을 세우고 첫 번째 착공을 시작하는 것과는 매우 다른 것처럼 이러한 프로세스도 매우 다릅니다.
- 다행스럽게도 앱을 만드는 데 건물 건설과 같은 세심한 계획이 필요하지 않습니다. Bubble의 유연성 덕분에 개발을 진행하면서 실험하고 아이디어를 생성할 수 있습니다.
- 여기서 목표는 나중에 작업의 노고를 줄일 수 있도록 앱에 견고한 기반을 제공하는 계획을 세우는 것입니다.
다음으로 빌드를 시작하기 전에 염두에 두어야 할 중요한 사항들을 살펴보겠습니다.
1. 데이터베이스 구조
데이터베이스 구조의 설정은 주로 앱에 필요한 데이터 type을 설정하는 작업입니다.
- 예를 들어 작업 및 프로젝트를 관리하는 앱일 경우 일반적으로 이와 관련된 데이터 type을 생성합니다.
- 이런 설정은 관행적으로 예상되는 것이지만, 데이터 type에 필요한 보안 종류를 철저하게 계획하는 것이 좋습니다. 이는 데이터베이스에서 데이터를 구성하는 방법에 영향을 미칠 수도 있습니다.
요점은 계획의 중요성을 다시 강조하는 것입니다. 앱의 동작의도를 정확히 알고 있다면 올바른 개인 정보 보호 규칙 및 조건식을 용이하게 사용할 수 있도록 데이터베이스 구조를 계획할 수 있습니다.
이것들을 설명하기 위해 다음의 몇 가지 예시를 살펴보겠습니다.
1) 작업 소유자 (작업 접근자)
작업에 대한 접근을 제어하는 개인정보 보호 규칙을 설정한다고 가정해 보겠습니다.
- 작업을 생성한 사용자만 작업을 보고 변경할 수 있는 액세스 권한이 있어야 합니다. 이 문제를 해결하는 확실한 방법은 작성자 필드를 사용하여 작업에 대한 접근을 제어하는 개인 정보 보호 규칙을 설정하는 것입니다.
- 하지만 소유권을 이전하고 작업을 할당하는 방법을 포함하고 싶다면 어떻게 해야 할까요?
작성자 필드는 소유권 이전을 어렵게 만드는 편집 불가능한 기본 제공 필드입니다. (여기서는 Created by 필드)
이 시나리오에서는 소유권을 넘겨받아을 수 있는 사용자 유형의 별도 필드를 설정하는 것이 필요합니다.
2) 여러 클라이언트 조직이 있는 SaaS
이 프로젝트 관리 도구를 팀 구성원들이 함께 일하는 여러 클라이언트 조직에 각각 제공했다고 가정해 보겠습니다. 예를 들어 직원 목록이 있는 회사일 수 있습니다.
- 이 경우 각 클라이언트의 데이터는 완전히 격리되어야 합니다.
- 이것이 의미하는 바는 한 조직의 데이터가 다른 조직에 속한 직원에게 절대 표시되어서는 안 된다는 것입니다.
이는 데이터베이스에 무엇을 의미합니까?
- 이는 모든 데이터(이 예시에서는 사용자, 작업 및 프로젝트)에 해당 상위 조직에 대한 필드가 포함되어야 함을 의미합니다.
- 즉, Bubble은 각 데이터베이스 항목이 속한 조직을 확인하고 액세스를 제한할 수 있어야 합니다.
- 프로젝트나 작업의 조직이 해당 프로젝트나 작업에 접근하려는 사용자의 조직과 동일하지 않은 경우 접근을 차단해야 합니다.
3) 전체, 부분 공유 또는 공유 없음
데이터베이스를 계획할 때 중요한 또 다른 측면은 특정 항목이 공유되는 방법입니다.
모든 데이터에는 기본적으로 세 가지 옵션이 있습니다.
- 누구와도 공유하지 않음
- 선택한 그룹 또는 사람들과 공유
- 모든 사람과 공유
물론 세 가지 지점이 겹칠 수도 있습니다.
- 예를 들어 Google Docs와 같은 클라우드 서비스에 저장된 문서를 생각해 보세요
- 일반적으로 누구와도 공유되지 않지만 Google에서는 선택한 수의 사용자를 선택하거나, 하나 이상의 그룹을 추가하거나, URL 액세스 권한이 있는 모든 사람에게 제공하는 링크를 설정할 수 있는 유연한 공유 기능을 제공합니다.
때로는 다음과 같은 다양한 권한으로 데이터가 공유되는 경우도 있습니다.
- 보기만 하고 편집하지는 않음
- 보고 댓글을 달 수 있지만 편집할 수는 없음
- 전체 편집 권한
- 게시 상태만 알기
일부 데이터베이스에는 해당 주기의 상태에 따라 정보의 노출이 결정되는 일종의 수명주기도 있습니다. 다음의 몇 가지 예시를 살펴보겠습니다.
- 블로그 게시물이나 기사에는 해당 작성자가 아닌 다른 사용자가 볼 수 있는지 여부를 결정하는 초안 및 게시 상태가 있을 수 있습니다. 또한 작성자가 지정된 날짜와 시간 이후에 공개적으로 공유할 수 있는 게시 날짜가 있을 수도 있습니다.
- 전자 상거래 제품도 마찬가지로 초안 및 게시 상태와 게시 날짜를 가질 수 있습니다.
- 더 이상 구매할 수 없을 때 숨기기 위해 매진과 같은 상태를 가질 수도 있습니다.
2. 페이지 보안
해당 페이지 구축을 시작하기 전에 앱의 각 페이지에 어떤 종류의 콘텐츠가 포함되어 있는지 명확한 개요를 갖는 것이 좋습니다. 그 이유는 간단합니다. 일부 페이지는 공개되고 다른 페이지는 공개되지 않습니다. 페이지가 어떤 카테고리에 속하는지 미리 알면 처음부터 올바른 방식으로 페이지를 구축하는 것이 더 쉽습니다.
120. 버블의 Page 보안 설정 (중급): javascript 코드 보안, workflow 보안, Optimize Application, 서버측 redirection
3. 데이터 저장과 보안
1) 자동 바인딩(Auto binding)으로 데이터 저장
자동 바인딩을 사용하면 사용자가 변경한 입력 필드가 포커스를 잃자마자 해당 입력 필드의 변경 사항을 즉시 저장할 수 있습니다.
- 이는 변경 사항을 저장하는 빠른 방법일 뿐만 아니라 개인 정보 보호 규칙에 의해 보호된다는 장점도 있습니다. 올바른 규칙을 설정하면 사용자는 자신이 저장하지 않는 항목이나 필드에 대한 접근 및 변경 사항을 절대 저장할 수 없습니다.
2) workflow로 데이터 저장
데이터 저장에 대한 두 번째 대안은 버튼 클릭과 같은 사용자 상호 작용에 의해 종종 트리거 되는 워크플로를 사용하는 것입니다. 워크플로에서 수행된 데이터베이스 변경사항은 동일한 방식으로 개인 정보 보호 규칙으로 보호되지 않으며 동일한 보호를 제공하려면 서버 측 조건식이 필요합니다.
- 이는 앱에 적합한 것이 무엇인지 고려해야 하는 순전히 사용자 인터페이스 결정입니다.
- 그러나 미리 계획하면 워크플로의 조건식을 사용하여 데이터를 보호할지, 아니면 개인 정보 보호 규칙을 사용하여 데이터를 보호할지 결정할 수 있습니다.
4. 사용자 역할에 따른 보안
많은 애플리케이션에는 다음과 같은 다양한 유형의 사용자가 있습니다.
- 로그인 또는 로그아웃 중인 사용자
- 관리자 권한이 있는 사용자
- 데이터를 만드는 사용자, 읽기만 하는 사용자
- 관리자와 관리권한 개발자 팀(최고 관리자라고도 함)
물론 앱에 따라 더 많은 카테고리가 있을 수 있습니다. 그러나 크게 보면, 사용자 역할은 대개 두 부분으로 나뉩니다.
- 사용자가 갖고 있는 역할 (예: 관리자, 작성자, 일반 사용자)
- 해당 역할과 함께 제공되는 권한 (예: 특정 항목 보기, 데이터베이스 변경, 다른 사용자 관리 등)
데이터베이스와 페이지 모두 각 역할에 대한 권한과 제한 사항을 중심으로 설계되어야 하므로 앱의 다양한 역할을 이해하는 것이 얼마나 중요한지 알 수 있습니다.
다음은 해당 구조를 설정하는 데 도움이 될 수 있는 몇 가지 질문입니다.
- 내 앱에는 어떤 역할이 있나요? (로그인한 사용자, 로그아웃사용자라는 기본 제공 역할을 포함하는 것을 잊지 마세요)
- 서로 다른 사용자 역할을 어떻게 분리합니까? (예를 들어 사용자에게 admin이라는 예/아니요 필드가 있거나 옵션 세트에 다른 역할을 저장할 수 있습니다.)
- 각 역할에는 어떤 권한과 제한사항이 있나요?
- 이것이 어떤 영향을 미칩니 까? (개인 정보 보호 규칙, 데이터베이스 구조, 워크플로우, 조건식에 따른 페이지 접근)
- 앱과 해당 데이터를 관리하려면 나와 내 팀에 별도의 역할과 페이지가 필요합니까?
앱의 특성에 따라 이 목록은 관련성이 없거나 충분하지 않을 수 있지만 사용자 역할의 의미에 대한 아이디어를 제공합니다. 때로는 선택한 사용자에게만 접근을 허용하여 데이터를 제한해야 하는 경우도 있습니다.
