이 페이지에서는 Cloud Key Management Service API의 필드를 사용하여 클라이언트 시스템과 Cloud KMS 간에 데이터가 이동될 때 데이터 변경을 감지하고 의도치 않은 변경을 방지하는 방법을 설명합니다. 이 가이드라인은 Google Cloud가 저장 중인 데이터와 전송 중인 데이터를 자동으로 보호하는 방법에 대한 보충 설명입니다.
자동 데이터 보호
Google Cloud의 모든 데이터는 Google Cloud 내에서 전송 중 및 저장 중에 자동으로 암호화됩니다.
Cloud KMS는 키 암호화 키(KEK)라는 또 다른 암호화 키를 사용해서 각 암호화 키를 암호화여 저장 중인 암호화 키를 보호하는 추가 단계를 수행합니다. 이 기법에 대해 자세히 알아보려면 봉투 암호화를 참조하세요.
각 Cloud KMS 암호화 작업에는 데이터 손상에 대한 자동 확인이 포함됩니다. 손상이 감지되면 작업이 중단되고 자세한 오류가 로깅됩니다.
이러한 자동 보호가 중요하지만 클라이언트 측 데이터 손상을 방지하지는 않습니다. 예를 들어 암호화 중에 데이터가 손상되면 데이터를 복호화하지 못할 수 있습니다.
이 주제에서는 데이터 손실 위험을 최소화하기 위해 클라이언트 측 데이터 손상을 감지하고 방지하는 방법을 설명합니다.
체크섬 계산 및 확인
각 암호화 작업의 요청 및 응답에는 plaintext_crc32c와 같은 CRC32C 체크섬 필드가 포함됩니다. 체크섬을 계산하고 계산된 값과 반환된 값을 비교할 수 있습니다.
서버에서 Cloud Key Management Service API는 관련 체크섬이 수신된 것을 나타내기 위해 verified_plaintext_crc32c와 같은 부울 필드를 true로 설정하고, 체크섬이 서버에서 계산된 값과 일치하지 않을 경우 INVALID_ARGUMENT 오류를 반환합니다.
체크섬을 계산하고 비교할 때는 다음 가이드라인에 유의하세요.
데이터가 전송되거나 수신되는 즉시 바이너리 인코딩을 사용하여 체크섬을 계산하세요.
Cloud Key Management Service API에서 전송되거나 수신되는 암호화되지 않은 일반 텍스트 체크섬을 저장하지 마세요. 예를 들어 EncryptRequest.plaintext_crc32c 또는 DecryptResponse.plaintext_crc32c 필드의 암호화되지 않은 내용을 저장하지 마세요.
체크섬 레코드를 보존하려면 관련 데이터와 함께 직렬화하고 복합 객체를 암호화하도록 Cloud KMS로 전달합니다. 데이터를 복호화할 때는 계산된 예상 값으로 체크섬을 확인할 수 있습니다.
복호화 작업으로 일치하지 않는 체크섬이 발생하는 경우, 일시적인 문제일 수도 있으므로, 제한된 횟수만 작업을 재시도하도록 애플리케이션을 디자인합니다.
암호화 작업으로 암호화된 데이터(암호문)에 대해 일치하지 않는 체크섬이 발생하는 경우, 암호화된 결과를 버리고 다시 시도합니다.
암호화 요청의 경우:
요청에 체크섬 필드를 포함하면, 체크섬 수신과 해당 값 확인이 시도되었음을 나타내기 위해 서버가 응답에서 관련 확인 필드를 true로 설정합니다.
체크섬 필드를 포함하지만 응답이 확인 필드를 false로 설정하는 경우, 서버가 체크섬 필드를 수신하지 않았거나 다른 정보가 응답에서 누락된 것일 수 있습니다. 일시적인 오류일 수도 있으므로 제한된 횟수만 요청을 재시도합니다.
체크섬이 수신되었지만 일치하지 않으면 INVALID_ARGUMENT 오류가 반환됩니다. 오류에는 일치하지 않은 필드 및 체크섬 이름이 포함됩니다. 예를 들면 다음과 같습니다.
The checksum in field plaintext_crc32c did not match the data in field plaintext.
일시적인 오류일 수도 있으므로 제한된 횟수만 요청을 재시도합니다.
복호화 요청의 경우 체크섬을 계산하고 이를 응답의 DecryptResponse.plaintext_crc32c 값과 비교할 수 있습니다.
다음 체크섬 필드는 Cloud Key Management Service API에 대한 요청 및 응답에 포함됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-21(UTC)"],[],[],null,["# Verifying end-to-end data integrity\n\nThis page discusses using fields in the Cloud Key Management Service API to detect and prevent\nunintended changes to data as it moves between client systems and\nCloud KMS. These guidelines supplement the ways that Google Cloud\n[automatically protects your data](#automatic_data_protection) at rest and in\ntransit.\n\nAutomatic data protection\n-------------------------\n\nAll data on Google Cloud is automatically encrypted\n[in transit](/security/encryption-in-transit) and\n[at rest](/security/encryption/default-encryption) within\nGoogle Cloud.\n\nCloud KMS takes extra steps to protect encryption keys at rest\nby encrypting each encryption key using another cryptographic key called a\n*key encryption key* (KEK). To learn more about this technique, refer to\n[envelope encryption](/kms/docs/envelope-encryption).\n\nEach Cloud KMS cryptographic operation includes automatic checks\nfor data corruption. If corruption is detected, the operation is aborted and\na detailed error is logged.\n\nThese automatic protections are important, but they don't prevent client-side\ndata corruption. For example, data corruption during encryption can lead to data\nthat can't be decrypted.\n\nThis topic discusses ways to detect and prevent client-side data corruption to\nminimize the risk of data loss.\n| **Note:** It is strongly recommended that callers utilize the integrity verification scheme described below to minimize the risk of data loss caused by in-transit data corruption.\n\nCalculating and verifying checksums\n-----------------------------------\n\nEach cryptographic operation's request and response include\n[CRC32C checksum](http://tools.ietf.org/html/rfc4960#appendix-B)\nfields, such as `plaintext_crc32c`. You can calculate the checksum and compare\nthe calculated and returned values.\n\nOn the server, the Cloud Key Management Service API sets boolean fields, such as\n`verified_plaintext_crc32c`, to `true` to indicate that it received the relevant\nchecksum, and returns an `INVALID_ARGUMENT` error if the checksum doesn't match\nthe value calculated by the server.\n\nKeep the following guidelines in mind when calculating and comparing checksums:\n\n- Calculate checksums, using a binary encoding, as soon as data is sent or received.\n- Do not store unencrypted plaintext checksums to or from the Cloud Key Management Service API. For example, do not store the unencrypted contents of the `EncryptRequest.plaintext_crc32c` or `DecryptResponse.plaintext_crc32c` fields. To keep a record of a checksum, serialize it along with the relevant data and pass the compound object to Cloud KMS for encryption. When you decrypt data, you can verify the checksum against your calculated expected value.\n- If a decryption operation results in mismatched checksums, design your application to retry the operation a limited number of times, in case of transient problems.\n- If an encryption operation results in mismatched checksums for the encrypted data (the ciphertext), discard the encrypted result and try again.\n\nFor encryption requests:\n\n- If you include the checksum field in the request, the server sets a related\n verification field in the response to `true`\n to indicate that it received the checksum and attempted to verify its value.\n\n- If you include the checksum field but the response sets the verification field to\n `false`, the server did not receive the checksum field, and other information may\n be missing from the response. Retry the request a limited number of times in case\n the error is transient.\n\n- If the checksum was received but did not match, an `INVALID_ARGUMENT` error is\n returned. The error includes the name of the field and the checksum that didn't\n match. For example:\n\n ```\n The checksum in field plaintext_crc32c did not match the data in field plaintext.\n ```\n\n Retry the request a limited number of times in case the error is transient.\n\nFor decryption requests, you can calculate a checksum and compare it to the\nvalue of `DecryptResponse.plaintext_crc32c` in the response.\n\nThe following checksum fields are included in requests to and responses from the\nCloud Key Management Service API.\n\nVerifying resource names\n------------------------\n\nResponses for\n[Encrypt](/kms/docs/reference/rpc/google.cloud.kms.v1#google.cloud.kms.v1.EncryptResponse),\n[GetPublicKey](/kms/docs/reference/rpc/google.cloud.kms.v1#publickey),\n[AsymmetricSign](/kms/docs/reference/rpc/google.cloud.kms.v1#asymmetricsignresponse),\n[MacSign](/kms/docs/reference/rpc/google.cloud.kms.v1#macsignresponse),\nand\n[MacVerify](/kms/docs/reference/rpc/google.cloud.kms.v1#macverifyresponse),\ninclude a `name` field that contains the name of the relevant Cloud Key Management Service API\nobject. You can compare the value of the `name` field to the value you expect,\nand discard results that do not match.\n| **Note:** The `EncryptRequest.name` field can contain either a CryptoKey name or a CryptoKeyVersion name. However, the `EncryptResponse.name` field always contains a `CryptoKeyVersion` name. To convert a `CryptoKeyVersion` name to a CryptoKey name, strip `/cryptoKeyVersions/` and its value (such as `/cryptoKeyVersions/2`) from the field.\n\nData verification diagram\n-------------------------\n\nThis diagram shows when to verify each type of data related to cryptographic\noperations and when to verify data from each type of source. You can also view\na [summary of the data verification fields](#data_verification_field_summary).\n\nData verification field summary\n-------------------------------\n\nUse this tables when designing your application, to determine which fields you\ncan use to verify your data before and after each cryptographic operation.\n\n### Encrypt\n\n### Decrypt\n\n### AsymmetricSign\n\n### AsymmetricDecrypt\n\n### PublicKey\n\n### MacSign\n\n### MacVerify\n\nWhat's next\n-----------\n\n- Learn more about [symmetric](/kms/docs/encrypt-decrypt) and [asymmetric](/kms/docs/encrypt-decrypt-rsa) encryption\n- Learn more about [encrypting application data](/kms/docs/encrypting-application-data)\n- Use [Cloud Audit Logs](/kms/docs/audit-logging)"]]
