동기화 게이트웨이

카우치베이스 라이브 뉴욕: Couchbase Mobile 102 - 모바일 애플리케이션에 보안 동기화를 추가하는 방법

102 세션의 카우치베이스 라이브 뉴욕 모바일 트랙의 코드에 설명된 Couchbase Mobile 샘플 애플리케이션을 계속 반복했습니다. "카우치베이스 모바일 101: 첫 번째 모바일 앱을 구축하는 방법" 세션.

카우치베이스 모바일 102 세션에서는 다음과 같은 내용을 살펴보았습니다. 동기화 게이트웨이 의 기능에 대해 자세히 알아보고, 깃허브 리포지토리에서 찾을 수 있는 Grocery Sync 샘플 애플리케이션을 통해 "모바일 애플리케이션에 보안 동기화를 추가하는 방법"에 대해 자세히 알아보세요. iOS 그리고 Android. 이 블로그에서는 동기화 게이트웨이에 대해 설명한 내용을 살펴봅니다. 동기화 게이트웨이는 Couchbase Lite와 Couchbase Server를 하나로 묶는 구성 요소입니다. 슬라이드를 참조하세요. 에 대한 주제와 코드 스니펫에 대해 설명합니다.

주요 모바일 데이터 보안 문제

동기화 게이트웨이가 해결하는 데 도움이 되는 영역 중 하나는 데이터 복제이며, 이는 클라우드에서 장치의 모바일 애플리케이션으로 데이터가 앞뒤로 동기화되는 방식에 관한 것입니다. 복제가 이루어지기 전 사용자 인증은 데이터 파티셔닝이 이루어질 때 동기화 게이트웨이가 처리하는 또 다른 핵심 영역입니다. 복제가 완료되면 사용자가 특정 데이터를 배포할 위치를 결정할 수 있도록 데이터를 적절히 파티셔닝해야 합니다. 그리고 데이터 액세스 제어가 있는데, 인증된 사용자에게 동기화 게이트웨이가 그에 따라 읽기 및 쓰기 권한을 설정하는 데 도움을 줄 수 있습니다. 각각에 대해 자세히 살펴보겠습니다.

[1] 사용자 인증

카우치베이스 모바일이 지원하는 플러그형 인증 모델을 사용하면 동기화 게이트웨이에서 애플리케이션 아키텍처의 보안 프레임워크에 대한 사용자 지정 구성이 가능한 다양한 방법으로 인증을 구현할 수 있습니다. 동기화 게이트웨이는 '기본 인증', 'Facebook', '페르소나' 인증 모델을 통해 세 가지 퍼블릭 공급업체를 지원합니다..

Facebook 인증: 동기화 게이트웨이 구성
아래 코드 스니펫은 동기화 게이트웨이용 Facebook을 구성하는 방법을 설명합니다.

구성 파일에서 Facebook을 인증 공급자로 사용하도록 정의했습니다. 이 시점 이후에는 동기화 게이트웨이가 클라이언트의 토큰을 인증하기 위해 Facebook과 통신하는 작업을 수행합니다.
사용자 지정 공급자 인증: 통신 경로   
LDAP 서버 설정에서 사용자 기반이 존재하는 사용자 지정 공급자를 구현하려면 모바일 애플리케이션이 먼저 앱 또는 인증 서버를 가리킵니다. 그런 다음 인증 서버가 사용자 인증을 담당하며, 사용자를 성공적으로 인증하면 인증 서버는 두 번째 단계에서 동기화 게이트웨이 관리자 API를 호출하여 해당 사용자에 대한 유효한 세션을 가져옵니다. 그런 다음 해당 세션 토큰은 다시 인증 서버로 라우팅된 다음 모바일 클라이언트로 반환됩니다. 모바일 애플리케이션이 토큰을 획득한 후 세 번째이자 마지막 단계는 세션 토큰을 사용하여 동기화 게이트웨이와 직접 통신하여 장치에서 사용자에게 필요한 모든 데이터를 가져오는 것입니다.
[2] 데이터 읽기 및 쓰기 액세스

많은 보안 질문은 읽기 및 쓰기 액세스를 관리하는 방법에 관한 것입니다. 동기화 게이트웨이를 사용하면 문서 수준에서 읽기 측 정책에 대한 세분화된 보안 정책을 정의한 다음 필드 수준까지 쓰기 측 정책을 정의할 수 있습니다. 일반적인 정책 시행 프레임워크는 복잡한 보안 규칙을 유연하게 정의하여 Couchbase Lite를 실행하는 모바일 애플리케이션으로 확장할 수 있는 Javascript 동기화 기능을 기반으로 합니다.

동기화 기능: 동기화 게이트웨이 구성

동기화 함수는 읽기-쓰기 액세스를 관리하는 방법에 대한 동기화 게이트웨이의 핵심이며 대부분의 데이터 액세스 규칙이 정의되는 곳입니다. 따라서 동기화 함수는 JSON 문서가 동기화 게이트웨이에 기록될 때마다 실행되는 JavaScript 함수이며, 보안 구현의 핵심입니다.

이 함수는 동기화 게이트웨이 구성 파일에 정의되어 있으며, 메서드 서명은 문서의 현재 수정본인 doc와 이전 수정본인 oldDoc을 취합니다. 메서드 본문은 이 두 가지 입력을 기반으로 보안 규칙이 정의되는 곳입니다. 여기에서 간단한 기본 동기화 기능을 먼저 정의한 다음 모든 경우에 적용할 수 있는 고급 보안 규칙을 서서히 구축할 수 있습니다. 이 접근 방식을 사용하면 새로운 문서 유형이 정의되거나 JSON 스키마가 변경되는 경우 동기화 함수를 수정할 수 있습니다.

동기화 기능: 쓰기 권한

쓰기 측 보안을 사용하면 알려진 사용자로부터 오는 특정 문서가 백엔드 저장소에 쓰여질 수 있는지 여부를 확인할 수 있습니다. 동기화 게이트웨이의 경우 동기화 기능에는 쓰기 측 권한에 사용할 수 있는 네 가지 주요 방법이 있습니다:
  1. 요구 사용자(): 사용자 ID 목록을 입력으로 받고 현재 활성 사용자가 해당 목록에 속하는지 확인합니다.
  2. requireRole(): 요구 사용자에게 특정 역할이 부여되었는지 확인할 수 있는 역할 목록을 입력으로 받습니다. 부여되지 않은 경우 문서가 거부됩니다.
  3. requireAccess(): 현재 사용자의 목록과 채널 목록을 입력으로 받아 특정 채널이 부여되었는지 확인합니다. 사용자가 목록에 포함되지 않으면 거부됩니다.
  4. throw(): 던지기를 사용하면 들어오는 문서에 대해 원하는 검사를 수행할 수 있습니다. 예를 들어 문서의 유형이 'item'인 경우 유효성 검사를 수행하여 유형이 일치하지 않으면 문서를 거부할 수 있습니다. 마찬가지로 특정 범위 내에 있는 값을 기반으로 유효성 검사를 수행할 수도 있습니다. 따라서 동기화 함수에서 구현할 수 있는 매우 세분화된 필드 수준 유형 유효성 검사는 해당 기준을 충족하지 않는 문서에 throw() 메서드와 함께 사용할 수 있습니다. throw()를 사용하면 오류가 발생한 이유와 문서가 거부된 이유에 대한 오류 세부 정보도 제공할 수 있습니다.

동기화 기능: 읽기 권한

읽기 측 보안을 사용하면 문서에 '채널()' 프리미티브를 사용해 데이터를 분할하고 사용자는 '액세스()' 프리미티브를 사용해 다른 채널에 할당되는 '채널'을 사용할 수 있습니다. 여기서 개념은 모든 문서가 하나 이상의 채널 세트와 연결되고 모든 사용자 역할이 읽을 수 있는 채널 세트를 갖는다는 것입니다.

채널 명령을 사용하여 사용자를 채널에 할당하는 즉시 특정 채널이 존재하게 됩니다. 이 시점에서 사용자는 동일한 채널 이름으로 태그가 지정된 문서를 찾게 됩니다. 별표[*]와 느낌표[!] 매개변수가 있는 두 개의 특수 채널이 존재합니다.

  1. 스타[*]: 스타 채널은 모든 문서가 해당 채널에 자동으로 추가되는 채널입니다. 예를 들어 게스트 사용자에게 * 별표 채널이 부여되면 모든 문서에 대한 개방형 액세스 권한을 갖게 됩니다. 이 채널 속성의 명확한 사용 사례는 채널에 * 별표가 있는 모든 사용자가 시스템의 모든 문서를 볼 수 있는 관리자 권한과 유사합니다.
  2. 느낌표[!] 두 번째 특수 채널은 ! 느낌표 속성으로, 문서를 공개 채널에 추가하면 모든 사용자가 해당 특정 문서를 볼 수 있는 문서 관점에서 초점을 맞춘 공개 채널을 설명하는 데 사용됩니다. 이 채널 속성의 명확한 사용 사례는 공개 공지를 위한 문서를 만들거나 모든 사용자에게 메시지를 방송하는 것과 유사합니다.

동기화 기능: 예제

다음 예제에서는 다음과 같이 살펴보겠습니다. 위에서 설명한 기능을 사용하여 보안을 유지하는 방법 식료품 동기화 애플리케이션은 Couchbase Mobile 101 세션에서 다음과 같이 존재합니다. 개인 정보가 보호되지 않는 완전히 보안되지 않은 애플리케이션입니다. 동기화 게이트웨이를 반복하면 사용자는 추가되는 모든 항목이 동일한 목록에 표시되는 것이 아니라 자신의 항목만 보게 됩니다.

동기화 게이트웨이의 시작 구성 파일은 아무것도 켜져 있지 않은 상태이며 Grocery 동기화 애플리케이션과 함께 제공되는 기본 설정입니다. 또한 게스트 사용자를 활성화하여 사용자가 모든 채널에 액세스할 수 있도록 함으로써 추가된 모든 문서와 새 항목을 볼 수 있도록 합니다. 보안을 추가하기 위해 가장 먼저 해야 할 일은 아래에서 구현할 사용자 인증입니다.

이 아이디어는 애플리케이션의 일부인 개별 사용자를 식별하고 이를 앱 내 보안 조치로 사용하는 것입니다. 구성 파일을 업데이트하여 Alice와 Bob이라는 사용자를 만듭니다. 게스트 계정을 제거하고 기본 인증을 사용하여 두 사용자를 미리 정의하여 처음에는 사용자가 모든 채널에 액세스할 수 있는 권한을 갖도록 합니다. 이제 사용자가 생성되었으므로 앱에서 사용자에 대한 읽기 및 쓰기 보안 로직을 정의할 수 있는 사용자 지정 동기화 기능을 만들려고 합니다.

이제 플레이스홀더 동기화 기능을 추가하고 여기에서 시스템 내 데이터에 대한 사용자의 액세스 제어를 제공하기 위해 로직을 집중하고 계속 반복할 것입니다. 다음으로 특정 채널 이름을 제공하여 채널을 더욱 안전하게 보호할 것입니다. 

이제 동기화 게이트웨이 구성에서 관리자 채널의 ["*"] 별표를 제거하여 사용자에게 자신의 항목 채널에 대한 액세스 권한을 부여하고 여기서의 경우처럼 "items-alice"와 같이 사용자에 특정한 새로운 비공개 채널을 추가합니다. 이전에는 ["*"] 채널을 사용하면 사용자가 시스템의 모든 문서를 볼 수 있었으므로 보안을 위해 이를 원하지 않았습니다. 'Bob'에 대해서도 마찬가지로 'admin_channels'를 "items-bob"으로 특정하도록 설정하여 동일한 작업을 수행합니다. 이렇게 하면 소유자만 항목에 액세스할 수 있으므로 식료품 문서에서 소유자 필드를 소유자 개인 항목 채널에 적절히 연결해야 합니다. 다음으로 동기화 기능을 추가로 수정하여 이를 수행하도록 하겠습니다.

문서가 동기화 게이트웨이에 작성되면 채널 이름이 '항목' 접두사가 붙은 형식의 채널에 문서를 할당합니다. 를 "doc.owner"에서 가져온 소유자 문서 내의 소유자 속성 값으로 대체할 수 있습니다. 이전 구성은 문서 속성이 'bob'으로 설정되어 있고 'items'가 'items-bob' 채널에 할당된 경우입니다. 사용자 'bob'은 'items-bob' 채널에 액세스할 수 있으며 기본적으로 이 채널은 Bob이 자신의 사용자 기록에서 액세스 권한을 부여받은 채널입니다. 이제 소유자가 'bob'인 모든 항목은 Bob이 해당 채널을 통해 볼 수 있지만 'items-alice' 채널에 있지 않으므로 Alice는 볼 수 없습니다. 이 구성에서 발생한 것은 문서를 적절한 채널에 할당하고 소유자 'items-' 채널을 통해 소유자에게 프로그래밍 방식으로 액세스 권한을 부여했기 때문입니다.

이제 사용자는 자신의 항목과 사실상 자신의 식료품 목록만 보거나 읽을 수 있습니다. 하지만 여전히 서로의 목록에 글을 쓸 수 있는데, Bob이 항목을 업로드하고 소유자 속성을 'Alice'로 설정하면 사실상 Bob이 Alice의 장보기 목록에 쉽게 침입할 수 있기 때문입니다. 보안을 강화하기 위한 다음 단계는 문서가 들어올 때 소유자 속성이 현재 인증된 사용자와 일치하는지 확인하는 것입니다.

업데이트된 구성은 이제 동기화 함수의 시작 부분에 문서 내에서 'doc.owner'를 통해 가져온 소유자 속성을 입력 매개변수로 하는 'requireUser' 함수를 포함합니다. 기본적으로 해당 문서를 업로드하려는 현재 인증된 사용자는 푸시업하려는 장보기 항목 문서의 소유자 속성과 일치하는 사용자 ID를 가지고 있어야 합니다.  그리고 일치하지 않으면 새 식료품 항목이 수락되지 않으므로 오류가 발생합니다. 이제 사용자는 자신만의 식료품 목록을 갖게 되며 아무도 쓸 수 없는 비공개 목록이 됩니다.
사용자가 친구를 추가해 특정 목록에 항목을 추가할 수 있다면 정말 멋질 것 같습니다. 설정에서 다음에 업데이트할 기능은 '친구의 문서 유형'이 있는 새로운 '문서' 유형을 추가하는 기능으로, 이 문서를 통해 친구에게 특정 사용자의 장보기 목록에 대한 액세스 권한을 부여할 수 있습니다.

이제 두 문서에 '항목' 또는 '친구' 문서 유형별로 구분할 수 있는 '유형' 키가 있으므로, 동기화 기능에 스위치를 추가하여 동기화 기능 내에서 서로 다른 문서를 다른 방식으로 처리할 수 있도록 할 수 있습니다.
먼저 문서 유형을 확인하여 '친구' 유형인지 확인한 다음 'requireUser()' 메서드를 통해 문서 소유자 속성이 현재 인증된 사용자 ID와 일치하는지 확인하고 일치하지 않으면 소유자만 친구를 초대하여 식료품 목록을 업데이트할 수 있으므로 거부합니다. 소유자 속성이 현재 인증된 사용자와 일치하면 'items-doc.owner' 채널을 통해 모든 친구에게 액세스 권한을 부여합니다.
예를 들어 밥이 친구 문서를 올려 앨리스를 초대하면 기본적으로 앨리스에게 아이템-밥 채널에 대한 액세스 권한을 부여합니다.
그런 다음 '친구' 유형인 문서를 다음과 같은 채널에 매핑합니다. 'private-doc.owner', 이 경우에는 'private-bob'이 될 것이며, 이번에는 동적으로 생성된 채널이라는 점에 유의하세요. 사용자 기록 관리자 채널에서는 이 채널이 생성되지 않으며, 사용자가 처음 초대를 보낼 때 이 채널이 즉석에서 생성되는 것을 볼 수 있습니다. 이는 기본적으로 사용자가 초대한 친구 목록은 사용자 본인에게만 비공개이므로 다른 사람은 볼 수 없다는 것을 의미합니다. 그런 다음 'doc.owner' 또는 현재 인증된 사용자에게 새로 생성된 비공개 채널에 대한 액세스 권한을 부여합니다.
'기타' 절은 이 문서가 친구의 문서가 아닌 경우입니다, 를 입력하면 식료품 동기화 항목 문서가 되고 소유자 속성이 현재 인증된 사용자 ID와 일치하는지 다시 한 번 확인합니다. 이전과 마찬가지로요, 항목 소유자 속성의 'items-' 채널에 항목을 추가하고 해당 사용자에게 해당 채널에 대한 동적 액세스 권한을 부여합니다.
위의 스위치 로직으로 동기화 함수를 업데이트했지만, 실제로는 알 수 없는 문서 유형을 거부하는 테스트를 추가하여 '친구' 또는 '항목' 문서 유형이 아닌 경우 'throw()' 메서드를 호출하여 문서를 거부할 수 있습니다.

다른 모든 문서 유형을 캡처하기 위해 또 다른 'else' 절을 추가한 것을 볼 수 있으며, "잘못된 문서 유형" 메시지를 클라이언트에 다시 전송합니다. 이렇게 하면 사람들이 데이터베이스에 원하지 않는 내용을 입력하는 것을 막을 수 있습니다.
이제 친구를 초대했으니 실제로 친구에게 소유자 목록에 새 항목을 쓸 수 있는 기능을 제공하려고 합니다. 우리가 해야 할 일은 이전의 'requireUser()' 메서드를 변경하는 것입니다. 를 'requireAccess()'에 추가하면 소유자가 항목 채널에 항목을 쓸 수 있을 뿐만 아니라 해당 특정 채널에 대한 액세스 권한이 부여된 모든 사람이 새 항목을 추가/쓸 수 있습니다. 친구는 친구의 문서에서 초대를 통해서만 사용자의 아이템 채널에 대한 액세스 권한이 부여됩니다.

'requireUser()' 메서드 대신, 이를 이제 기본적으로 목록에 새 항목을 작성하려면 항목을 추가하려는 특정 사용자의 항목 채널에 대한 액세스 권한이 있어야 합니다. 앱의 추가 기능 중 하나는 친구가 목록에 새 항목을 작성하는 경우 해당 항목을 체크오프할 수 없도록 하는 것입니다. 그래서 우리가 원하는 것은 체크하지 않은 새 항목만 추가하도록 한 다음 식료품 목록의 소유자만 해당 항목을 체크할 수 있도록 하는 것입니다. 친구가 문서를 작성할 때 문서에 해당 속성이 true로 설정되어 있지 않은지 추가로 확인하여 doc.checked 속성의 부울 값을 테스트할 것입니다.

먼저 'oldDoc'이 null인지, 즉 새로 생성된 항목인지 확인합니다. 따라서 문서에서 'check' 속성을 확인하여 참인지 확인하고 참인 경우 를 사용하면 새 항목이 생성될 때 '새 항목을 확인할 수 없습니다'라는 오류가 발생합니다. 우리는 소유자가 항목이 생성되었을 때만 항목을 확인하거나 선택 취소하기를 원하며, 항목에 업데이트가 있음을 의미하는 (doc 및 oldDoc)이 있는지 확인한 다음 항목의 이전 버전과 새 버전 간에 'check' 속성이 변경되었는지 확인하여 이를 검증할 것입니다. 'oldDoc'이 NULL이 아닌지 간단히 확인한 다음 요구 사용자(소유자)를 확인할 수 있지만 친구가 항목의 텍스트에 있는 오타를 수정할 수 있기를 원합니다. 친구가 항목을 체크할 수 없더라도 항목 제목이나 레이블을 변경하고 싶을 수 있기 때문입니다. 다음으로 필드 수준 유효성 검사를 수행하여 이전 oldDoc이 존재하는지 여부를 확인합니다. 따라서 'doc.Checked'와 'oldDoc.checked'를 비교하여 변경되었는지 확인합니다. 그런 다음 변경된 경우 문서 소유자만이 확인란을 변경할 수 있으므로 문서 소유자에 대해 'requireUser(소유자)'를 수행합니다.

'else 절'을 살펴보면 항목의 이전 이전 버전과 푸시 중인 새 버전 간에 '확인' 값이 변경되었는지 확인하는 추가 코드가 있습니다. 변경된 경우 현재 인증된 사용자가 문서 소유자여야 합니다.
소유자만 확인란을 변경할 수 있도록 설정합니다. 그러나 소유자의 다른 친구는 항목의 제목과 같은 항목을 변경할 수 있습니다.
마지막으로 살펴보고 해결해야 할 문제가 하나 있습니다. 항목이 생성된 후에는 누구도 항목의 '소유자'를 변경할 수 없도록 하고 싶습니다. 즉, 친구는 라벨을 수정할 수는 있지만 항목의 확인란을 변경하거나 항목의 실제 소유자를 변경할 수는 없습니다. 최종 구성에서 이 문제를 어떻게 해결할 수 있는지 살펴보겠습니다.

따라서 추가 검사를 수행하여 'oldDoc != nil'이고 새 버전의 문서 소유자가 이전 버전의 소유자(doc.owner != oldDoc.owner)와 일치하지 않는 업데이트인 경우 오류를 던집니다. 이제 추가 테스트를 수행하여 이전 버전과 현재 버전 간에 소유자가 변경된 경우 기본적으로 문서 소유자를 변경할 수 없으므로 클라이언트에 오류를 반환하는 것을 볼 수 있습니다.

[3] 유선을 통한 데이터 전송

이제 보안과 관련된 사용자 액세스에 대한 인증 및 데이터 읽기/쓰기 문제를 제외하고, 다음 주제는 원격 엔드포인트로 전송되는 데이터의 보안을 보장하는 것입니다. 동기화 게이트웨이는 전송 시 SSL 및 TLS를 지원합니다. 모바일 앱의 데이터 보안을 강화하기 위해 Sync Gateway에서 SSL을 사용하도록 Sync Gateway 구성 파일 내에서 구성하는 것은 간단합니다.

[4] 데이터 스토리지

클라이언트의 데이터 저장소, 를 사용하면 실제로 장치에서 파일 시스템 암호화를 수행하고 있는 것입니다. 모바일 개발자 포털에 로컬 카우치베이스 라이트 데이터베이스를 암호화하기 위해 수행해야 하는 작업에 대한 좋은 정보가 있습니다. 여기서는 안전한 클라우드 환경과 클라이언트에서 파일 시스템 암호화를 위한 구성에 대해 설명합니다.

요약

동기화 게이트웨이의 진수 임베디드 장치에 있는 프레임워크인 Couchbase Lite를 하나로 묶어줍니다. 클라우드에서 실행 중인 Couchbase 서버가 있고 Sync Gateway가 이를 서로 연결합니다. 동기화 게이트웨이에는 로컬 장치에서 실행 중인 애플리케이션(독립형 연결 해제 애플리케이션)을 완전한 기능을 갖춘 다중 사용자 동기화 환경으로 전환하기 위해 제공하는 몇 가지 주요 기능이 있습니다. 위에 표시된 것은 동기화 함수 구성 파일을 반복하여 데이터베이스의 항목을 직렬화하는 방법입니다.

다음으로 살펴볼 Couchbase Lite HTTP 리스너 컴포넌트 클래스는 "Couchbase Mobile로 피어투피어 앱 구축"을 통해 고유한 소셜 인앱 경험을 만들 수 있는 피어투피어 기능을 활성화하는 방법에 대한 Couchbase Mobile 103 세션입니다.

이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

작성자

게시자 윌리엄 호앙, 모바일 개발자 옹호자, Couchbase

윌리엄은 카우치베이스의 모바일 엔지니어링/개발자 경험 팀의 개발자 옹호자였습니다. 커피와 코드에 대한 그의 사랑은 오프라인 대면 경험을 즐기면서 모바일의 세계로 넘어왔습니다. 그 전에는 Twitter, BlackBerry, Microsoft에서 개발자 관계 팀에서 일했으며, Research In Motion에서 소프트웨어 임베디드 GPS 엔지니어로 근무하기도 했습니다. 윌리엄은 맥길 대학교에서 전기 소프트웨어 공학을 전공했습니다.

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.