From 8ed648a63bd63c42bfb8b0b1ff576b3e91db58d6 Mon Sep 17 00:00:00 2001
From: pkm2 <44357530+pkm2@users.noreply.github.com>
Date: Wed, 14 Nov 2018 18:20:11 +0900
Subject: [PATCH] translate(part4): add park4
---
docs/root/source/permissions-ko.md | 65 +++++++++++++++
docs/root/source/private-data-ko.md.md | 108 +++++++++++++++++++++++++
2 files changed, 173 insertions(+)
create mode 100644 docs/root/source/permissions-ko.md
create mode 100644 docs/root/source/private-data-ko.md.md
diff --git a/docs/root/source/permissions-ko.md b/docs/root/source/permissions-ko.md
new file mode 100644
index 00000000..9ca1a994
--- /dev/null
+++ b/docs/root/source/permissions-ko.md
@@ -0,0 +1,65 @@
+
+
+BigchainDB 사용 권한
+-------------------------
+
+BigchainDB를 사용하면 다른 사용자가 할 수 있는 것을 어느 정도 제어할 수 있습니다.
+이 능력은 \*nix환경에서의 "권한", SQL에서의 "특권", 보안 환경에서의 "액세스 제어"와 유사합니다.
+
+
+출력 지출/이전 권한
+======================================
+
+BigchainDB에서, 모든 출력에는 연관된 조건(crypto-condition)이 있습니다.
+사용되지 않은 출력을 쓰거나 전송하려면, 사용자(또는 사용자 그룹)이 조건을 충족시켜야 합니다.
+특정 사용자만이 출력을 보낼 권한이 있다는 뜻입니다. 가장 단순한 조건은, "공용 키에 해당하는 개인 키를 가진 사람만이 출력을 보낼 수 있습니다." 훨씬 더 정교한 조건들도 가능합니다, 예를 들어 “이 출력을 사용하려면,…"
+
+- "…회계 그룹의 모든 사람이 서명 할 수 있습니다."
+- "…네 명 중 세 명이 서명해야 합니다."
+- "…Bob이 반드시 서명해야 하거나 Tom과 Sylvia 둘 모두가 서명해야 합니다."
+ 자세한 내용은, `BigchainDB Transactions Spec `_ 관련 **트랜잭션 구성요소:조건** 섹션을 참조하세요
+
+출력이 한번 소비되면 다시 사용할 수 없습니다: *아무도* 그렇게 할 권한이 없습니다. 즉, BigchainDB는 누구나 출력을 "이중 소비" 하도록 허용 하지 않습니다.
+
+
+쓰기 권한
+=================
+
+누군가 TRANSFER 트랜잭션을 만들면, ``metadata`` 필드에 임의의 JSON 객체를 넣을 수 있다.(적정 범위 내에서; 실제 BigchainDB 네트워크는 트랜잭션의 크기에 제한을 둔다.) 즉, TRANSFER 트랜잭션에서 원하는 모든 것을 쓸 수 있다.
+
+BigchainDB에서 "쓰기 권한"이 없다는 의미인가요? 아닙니다!!
+
+TRANSFER 트랜잭션은 입력이 이전 출력을 충족시키는 경우에만 유효(허용)합니다. 이 출력들에 대한 조건은 누가 유효한 TRANSFER 트랜잭션을 할 수 있는지 조절 할 것입니다. 즉, 출력에 대한 조건은 특정 사용자에게 관련 자산 내역에 무엇인가 쓸 수 있는 "쓰기 권한"을 부여하는 것과 같습니다.
+
+예를 들어, 당신은 BigchainDB를 사용하여 오직 당신만이 쓰기권한이 있는 공용 저널을 작성 할 수 있습니다. 방법은 다음과 같습니다: 먼저 하나의 출력으로 ``asset.data`` 을 통해 ``{"title": "The Journal of John Doe"}`` 와 같이 되도록 CREATE 트랜잭션을 생성합니다. 이 출력에는 금액 1과 사용자(개인 키를 가진)만이 출력을 보낼 수 있는 조건이 있습니다. 저널에 무엇인가를 추가하고 싶을 때마다, ``metadata`` 같은 필드에 최신 항목을 넣은 TRANSFER 트랜잭션을 새로 만들어야 합니다.
+
+.. code-block:: json
+
+ {"timestamp": "1508319582",
+ "entry": "I visited Marmot Lake with Jane."}
+
+TRANSFER 트랜잭션에는 하나의 출력이 있습니다. 이 출력에는 금액1과 사용자(개인키를 가진)만이 출력을 보낼 수 있는 조건이 있습니다. 기타 등등. 당신만이 자산 내역(당신의 저널)에 덧붙일 수 있습니다.
+
+이와 같은 기술은 공학 노트북,공급망 기록,정부 회의록 등에도 사용 될 수 있습니다.
+
+또한 더 정교한 것들도 할 수 있습니다. 예를 들어, 누군가가 TRANSFER 트랜잭션을 작성할 때마다, *다른 누군가*에게 사용 권한을 부여하여 일종의 작성자-전달 혹은 연쇄 편지를 설정한다.
+
+.. Note::
+
+ 누구나 CREATE 트랜잭션의 ``asset.data`` 필드에 있는 JSON(조건하에)을 쓸 수 있습니다. 허가가 필요하지 않습니다.
+
+
+읽기 권한
+================
+
+다음 타이틀의 페이지를 보십시오,:doc:`BigchainDB, Privacy and Private Data `.
+
+역할 기반 액세스 제어(RBAC)
+================================
+
+2017년 9월에, 우리는 `BigchainDB RBAC 하부 시스템을 정의 할 수 있는 방법에 대한 블로그 게시물 `_ 을 게재 했습니다.
+글을 쓴 시점(2018년 1월)에는 플러그인을 사용해야 해서, 표준 BigchainDB(다음에서 사용가능한 `BigchainDB Testnet `_) 를 사용 할 수 없었습니다. 이는 미래에 바뀔 수 있습니다. 만약 관심이 있다면, `연락하십시오 BigchainDB `_.
\ No newline at end of file
diff --git a/docs/root/source/private-data-ko.md.md b/docs/root/source/private-data-ko.md.md
new file mode 100644
index 00000000..daca19e8
--- /dev/null
+++ b/docs/root/source/private-data-ko.md.md
@@ -0,0 +1,108 @@
+
+
+BigchainDB, 개인정보 및 개인 데이터
+------------------------------------
+
+기본 정보
+===========
+
+#. 한도 내에서 BigchainDB 네트워크에 임의의 데이터(암호화 된 데이터 포함)를 저장 할 수 있습니다. 모든 트랜잭션에는 거의 모든 유니코드 문자열(최대 길이까지)을 저장 할 수 있는 ``metadata`` 섹션이 있습니다. 마찬가지로, 모든 CREATE 트랜잭션에는 거의 모든 유니코드 문자열을 저장 할 수 있는 ``asset.data`` 섹션이 있습니다.
+#. 특정 BigchainDB 거래 필드에 저장된 데이터는 암호화 해서는 안됩니다, 예를 들어 공용키 및 자산과 같이. BigchainDB는 Zcoin과 비슷한 개인 거래를 제공하지 않습니다.
+#. 데이터가 BigchinDB 네트워크에 저장되면 변경 또는 삭제 될 수 없다고 가정하는 것이 좋습니다.
+#. BigchainDB 네트워크의 모든 노드에는 저장된 모든 데이터의 전체 복사본이 있습니다.
+#. BigchainDB 네트워크의 모든 노드는 저장된 모든 데이터를 읽을 수 있습니다.
+#. BigchainDB 노드(예를 들어 노드이 sysadmin)에 대한 전체 액세스 권한을 가진 모든 사용자는해당 노드에 저장된 모든 데이터를 읽을 수 있습니다.
+#. BigchainDB HTTP API를 통해 노드에 접근하는 모든 사용자는 BigchainDB에 저장된 모든 데이터를 찾고 읽을 수 있습니다. 액세스 권한이 있는 사람들의 목록은 매우 짧을 수 있습니다.
+#. 외부 사용자와 BigchainDB 노드 사이의 연결이(예를 들어 HTTPS를 사용하여) 암호화되 않으면도청자는 전송중인 모든 HTTP 요청 및 응답을 읽을 수 있습니다.
+#. 만약 누군가가 평문에 접근 할 수 있다면(어디에서 가져왔는지 관계없이), 원칙적으로 이것을 전 세계와 공유 할 수 있습니다. 그렇게 하는 것을 어렵게 만들 수 있습니다, 예를 들어 데이터가 많고 방을 나갈 떄 검색되는 안전한 방 안에만 들어 갈 수 있는 것과 같습니다.
+
+오프 체인에서 개인 데이터 저장
+==============================
+
+시스템은 제3자 데이터베이스, 문서 저장소 또는 CMS(컨텐츠 관리 시스템)와 같은 오프 체인 데이터를 저장할 수 있으며, BigchinDB를 사용하여 다음 작업을 수행할 수 있습니다:
+
+- 제3자 시스템에 읽기 권한 또는 기타 권한이 있는 사용자를 추적합니다. 이 작업을 수행하는 방법의 예는 아래에 있습니다.
+- 제3자 시스템에 대한 모든 요청을 영구적으로 기록합니다.
+- 모든 문서의 변경 사항을 감지 할 수 있도록, 다른 곳에 저장된 문서의 해시를 저장합니다.
+- 암호화 된 터널을 설정했다는 것을 증명할 수 있도록 두 개의 오프 체인 파티(예:Diffie-Hellman 키 교환) 간의 모든 핸드셰이크 설정 요청 및 응답을 기록합니다(독자가 해당 터널에 액세스하지 않고). 이 아이디어에 대한 자세한 내용은 `the BigchainDB Privacy Protocols 저장소 `_ 에 있습니다.
+
+특정 문서에 대한 읽기 권한을 가진 사람을 기록하는 간단한 방법은 제 3자 시스템(“Docpile“)이 모든 문서+사용자 쌍에 대해 BigchinDB 네트워크에 CREATE 트랜잭션을 저장하여 해당 사용자가 그 문서에 대한 읽기 권한을 가지고 있음을 나타낼 수 있습니다. 트랜잭션은 Docpile에 의해 서명 될 수 있습니다(또는 문서 소유자에 의해). 자산 데이터 필드는 1)사용자의 고유 ID 및 2)문서의 고유 ID를 포함합니다. CREATE 트랜잭션의 한 출력은 DocPile(또는 문서 소유자)에 의해서만 전송/소비 될 수 있습니다.
+
+
+읽기 권한을 취소하기 위해, DocPile은 원래 사용자가 더 이상 해당 문서에 대한 읽기 권한을 가지고 있지 않다고 하는 메타 데이터 필드를 사용하여, 원래의 CREATE 트랜잭션에서 하나의 출력을 보내기 위한 TRANSFER 트랜잭션을 생성 할 수 있습니다.
+
+이는 무한정으로 수행될 수 있습니다,즉.사용자가 다시 읽기 권한을 가지고 있음을 나타내기 위해 다른 TRANSFER 트랜잭션을 DocPile에서 작성할 수 있습니다.
+
+Docpile은 CREATE → TRANSFER → TRANSFER → 사용자+문서 쌍에 대한 etc.chain 과정에서 사용자의 마지막 트랜잭션을 읽음으로써 주어진 문서에 대한 읽기 권한을 가지고 있는지 파악할 수 있습니다.
+
+여기에 같은 일을 하는 다른 방법들이 있다. 위는 단지 하나의 예시이다.
+
+위의 예시에서는 사용자가 소유한(통제 된)자산으로 “읽기 권한“을 취급하지 않았다는 것을 알 수 있습니다, 왜냐하면 사용 권한 자산이 사용자에게 주어 지면(사용자에 의해 양도되거나 사용자에 의해 생성된 경우) 사용자가 다시 Docpile로 전송 할 때까지 어떠한 것도 제어 할 수 없기 때문입니다(Docpile에 의해).
+
+체인에서 암호화 된 개인 데이터 저장
+========================================
+
+체인상에서 개인 데이터를 암호화하여 저장하는 방법에는 여러 가지가 있습니다. 모든 유스 케이스에는 고유한 목표와 제약이 있으며, 최상의 해결책은 유스 케이스에 달려있다.
+`BigchainDB 컨설팅 팀 `_, 우리의 파트너와 함께, 당신의유스 케이스에 가장 적합한 솔루션을 설계하는 데 도움을 줄 수 있습니다.
+
+아래에서는 다양한 암호화 기본 설정을 사용하여 가능한 시스템을 설정하는 예제를 설명합니다.
+
+참고 사항:
+
+- Ed25519 키 쌍은 `메시지 암호화 및 암호 해독이 아닌 `_ 암호화 서명 및 확인을 위해 설계되었습니다. 암호화의 경우, X25519와 같은 암호화를 위해 설계된 키 쌍을 사용해야 합니다.
+ -누군가(또는 어떤 그룹)이 체인상의 암호화 된 데이터를 해독하는 방법을 발표하면 암호화 된 데이터에 액세스 할 수 있는 모든 사람이 평문을 가져올 수 있습니다. 데이터는 삭제할 수 없습니다.
+ -암호화 된 데이터는 MongoDM에서 색인을 생성하거나 검색 할 수 없습니다.(암호문을 색인화하고 검색 할 수 있지만 유용하지는 않습니다.) 암호화 된 데이터를 색인화하고 검색하기 위해 준 유사 암호를 사용할 수 있지만, MongoDB는 이를 지원할 계획이 없습니다. 색인화 또는 키워드 검색이 필요한 경우 ``asset.data``의 몇가지 필드 또는 ``metadata``객체를 일반 텍스트로 남겨두고 민감한 정보를 암호화 된 하위 객체에 저장할 수 있습니다.
+
+시스템 예시 1
+~~~~~~~~~~~~~~~~
+
+대칭 키로 데이터를 암호화하고 체인에(``metadata`` 또는 ``asset.data`` 에서) 암호문을 저장하십시오. 키를 제 3자에게 알리려면, 공용 키를 사용하여 대칭 키를 암호화하고 암호화 키를 보냅니다.
+
+공용 키/ 개인 키 쌍과 함께 대칭 키를 사용하는 이유는 암호문을 한 번만 저장해야 하기 때문입니다.
+
+시스템 예시 2
+~~~~~~~~~~~~~~~~
+
+이 예시에서는 `프록시 재-암호화 `_ 를 사용합니다:
+
+#. MegaCorp는 자체 공용 키를 사용하여 일부 데이터를 암호화 한 후 암호화 된 데이터(암호문1)을 BigchainDB 네트워크에 저장합니다.
+#. MegaCorp는 다른 사람들이 암호화 된 데이터를 읽을 수 있게 하고 싶지만, 공용 키를 공유하지 않고 모든 새로운 수신자에 대해 스스로를 다시 암호화 할 필요가 없습니다. 대신 프록시 재 암호화 서비스를 제공하기 위해 Moxie라는 “프록시“를 찾습니다.
+#. Zorban은 MegaCorp에 연결하여 데이터 읽기 권한을 요청합니다.
+#. MegaCorp는 Zorban에게 공용 키를 요청합니다.
+#. MegaCorp “재 암호화 키“를 생성하여 프록시 Moxie로 전송합니다.
+#. Moxie (프록시)는 재 암호화 키를 사용하여 암호문 1을 암호화하고 암호문 2를 만듭니다.
+#. Moxie는 Zorban(또는 Zorban에게 전달하는 MegaCorp)에게 암호문 2를 보냅니다.
+#. Zorban은 개인 키를 사용하여 암호문 2를 해독해서 원본 암호화되지 않은 데이터를 가져옵니다.
+
+참고:
+
+- 프록시는 암호문만 볼 수 있습니다. 암호화 되지 않은 데이터는 볼 수 없습니다.
+- Zorban은 암호문 1, 즉 체인 상의 데이터를 해독 할 수 있는 능력이 없습니다.
+- 위의 흐름에는 다양한 변형이 있습니다.
+
+시스템 예시 3
+~~~~~~~~~~~~~~~~
+
+이 예시는 `삭제 코딩 `_ 을 사용합니다:
+
+#. 데이터를 n개의 조각으로 삭제하십시오.
+#. 서로 다른 암호화 키로 n개의 조각을 암호화 하십시오.
+#. n 개의 암호화 된 부분을 체인에 저장합니다 (예: n개의 별도 트랜잭션).
+#. n 개의 암호 해독 키 각각을 다른 당사자와 공유하십시오.
+
+만약 k< N 인 키홀더가 k개의 조각들을 가져와서 해독한다면, 그것들은 원본 텍스트를 다시 만들 수 있습니다. k미만이면 충분하지 않습니다.
+
+시스템 예시 4
+~~~~~~~~~~~~~~~~
+
+이 설정은 특수 노드가 데이터의 일부를 볼 수 있어야 하지만, 다른 노드는 볼 수 없어야 하는 기업용 블록 체인 시나리오에서 사용할 수 있습니다.
+
+- 특수 노드는 X25519 키 쌍 (또는 유사한 비대칭 *암호화*키 쌍)을 생성합니다 .
+- BigchainDB 최종 사용자는 특수 노드의 X25519 공용 키(암호화 키)를 찾습니다.
+ -최종 사용자는 위에서 언급 한 공용 키를 사용하여, asset.data 또는 메타 데이터(또는 모두)를 사용하여 유효한 BigchainDB 트랜잭션을 생성합니다.
+- 이는 asset.data 또는 메타 데이터의 내용이 유효성 검증에 중요하지 않은 트랜잭션에 대해서만 수행되므로, 모든 노드 운영자가 트랜잭션을 검증 할 수 있습니다.
+- 특수 노드는 암호화 된 데이터를 해독 할 수 있지만, 다른 노드 운영자와 다른 최종 사용자는 할 수 없습니다.
\ No newline at end of file