기본적으로 BigQuery는 저장 중 고객 콘텐츠를 암호화합니다. BigQuery는 사용자 측의 추가 작업 없이 자동으로 암호화를 처리합니다. 이 옵션을 Google 기본 암호화라고 부릅니다.
Google 기본 암호화는 Google이 자체 암호화된 데이터에 사용하는 것과 동일한 강화된 키 관리 시스템을 사용합니다. 이러한 시스템에는 엄격한 키 액세스 제어 및 감사가 포함됩니다.
각 BigQuery 객체의 데이터 및 메타데이터는 고급 암호화 표준(AES)을 사용하여 암호화됩니다.
암호화 키를 제어하려면 BigQuery를 포함한 CMEK 통합 서비스와 함께 Cloud KMS에서 고객 관리 암호화 키(CMEK)를 사용하면 됩니다. Cloud KMS 키를 사용하면 보호 수준, 위치, 순환 일정, 사용 및 액세스 권한, 암호화 경계를 관리할 수 있습니다.
Cloud KMS를 사용하면 키 사용을 추적하고, 감사 로그를 보고, 키 수명 주기를 제어할 수도 있습니다. Google에서 데이터를 보호하는 대칭 키 암호화 키(KEK)를 소유하고 관리하는 대신 사용자가 Cloud KMS에서 이러한 키를 제어하고 관리할 수 있습니다.
CMEK로 리소스를 설정한 후 BigQuery 리소스에 액세스하는 환경은 Google 기본 암호화를 사용하는 것과 유사합니다.
암호화 옵션에 대한 자세한 내용은 고객 관리 Cloud KMS 키를 참조하세요.
Cloud KMS Autokey를 사용하는 CMEK
CMEK를 수동으로 만들어 BigQuery 리소스를 보호하거나 Cloud KMS Autokey를 사용할 수 있습니다. Autokey를 사용하면 BigQuery에서 리소스를 만들 때 필요에 따라 키링과 키가 생성됩니다.
암호화 및 복호화 작업에 키를 사용하는 서비스 에이전트가 없으면 생성되며, 필요한 Identity and Access Management(IAM) 역할이 부여됩니다. 자세한 내용은 Autokey 개요를 참조하세요.
수동으로 생성된 CMEK를 사용하여 BigQuery 리소스를 보호하는 방법은 고객 관리 Cloud KMS 키를 참조하세요.
BigQuery 테이블 내에서 개별 값을 암호화하려면 연관 데이터로 암호화 인증(AEAD)이라는 암호화 기능을 사용합니다. 모든 고유 고객의 데이터를 공통 테이블에 보관하려면 AEAD 함수를 사용해서 서로 다른 키를 사용하여 각 고객의 데이터를 암호화합니다. AEAD 암호화 함수는 AES를 기반으로 합니다. 자세한 내용은 GoogleSQL의 AEAD 암호화 개념을 참조하세요.
클라이언트 측 암호화
클라이언트 측 암호화는 저장 데이터 BigQuery 암호화와 별개입니다. 클라이언트 측 암호화를 사용하도록 선택하면 클라이언트 측 키 및 암호화 작업을 사용자가 관리해야 합니다. 데이터를 BigQuery에 쓰기 전에 먼저 암호화해야 합니다. 이 경우 사용자 키와 Google 키를 사용하여 데이터가 두 번 암호화됩니다. 마찬가지로 BigQuery에서 읽혀지는 데이터도 Google 키와 사용자 키를 사용하여 두 번 복호화됩니다.
전송 중 데이터
읽기 및 쓰기 작업 도중 인터넷을 통해 전송되는 데이터를 보호하기 위해 Google Cloud 은 전송 계층 보안(TLS)을 사용합니다. 자세한 내용은 Google Cloud에서 전송 중 데이터 암호화를 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-01(UTC)"],[[["\u003cp\u003eBigQuery automatically encrypts customer data at rest using Google default encryption, which employs robust key management systems and the Advanced Encryption Standard (AES).\u003c/p\u003e\n"],["\u003cp\u003eCustomers can opt for customer-managed encryption keys (CMEKs) via Cloud KMS to gain more control over key protection, location, rotation, and access permissions.\u003c/p\u003e\n"],["\u003cp\u003eCloud KMS Autokey simplifies CMEK management by automatically generating key rings and keys during resource creation in BigQuery, and handles the creation of the necessary service agents.\u003c/p\u003e\n"],["\u003cp\u003eFor encrypting individual values within a table, BigQuery supports Authenticated Encryption with Associated Data (AEAD) encryption functions, allowing for different keys per customer.\u003c/p\u003e\n"],["\u003cp\u003eClient-side encryption can be implemented, providing a second layer of encryption before data is written to BigQuery, but users are fully responsible for the management of client-side keys and cryptographic operations.\u003c/p\u003e\n"]]],[],null,["# Encryption at rest\n==================\n\nBy default, BigQuery encrypts customer content at\nrest. BigQuery handles encryption for you without any\nadditional actions on your part. This option is called *Google default encryption* .\nGoogle default encryption\nuses the same hardened key management systems that we use for our own\nencrypted data. These systems include strict key access controls and auditing.\nEach BigQuery object's data and metadata is encrypted using the\n[Advanced\nEncryption Standard (AES)](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard).\n\nIf you want to control your encryption keys, then you can use customer-managed encryption keys\n(CMEKs) in [Cloud KMS](/kms/docs) with CMEK-integrated services including\nBigQuery. Using Cloud KMS keys gives you control over their protection\nlevel, location, rotation schedule, usage and access permissions, and cryptographic boundaries.\n\nUsing Cloud KMS also lets\nyou [track key usage](/kms/docs/view-key-usage), view audit logs, and\ncontrol key lifecycles.\n\n\nInstead of Google owning and managing the symmetric\n[key encryption keys (KEKs)](/kms/docs/envelope-encryption#key_encryption_keys) that protect your data, you control and\nmanage these keys in Cloud KMS.\n\nAfter you set up your resources with CMEKs, the experience of accessing your\nBigQuery resources is similar to using Google default encryption.\nFor more information\nabout your encryption options, see [Customer-managed Cloud KMS keys](/bigquery/docs/customer-managed-encryption).\n\nCMEK with Cloud KMS Autokey\n---------------------------\n\nYou can either create CMEKs manually to protect your BigQuery\nresources or use Cloud KMS Autokey. With Autokey, key rings and keys are generated on demand as\npart of resource creation in BigQuery.\nService agents that use the keys for encrypt and decrypt operations are created if they don't\nalready exist and are granted the required Identity and Access Management (IAM) roles. For more\ninformation, see [Autokey overview](/kms/docs/autokey-overview).\n\n\nTo learn how to use\nmanually-created CMEKs to protect your BigQuery resources, see\n[Customer-managed Cloud KMS keys](/bigquery/docs/customer-managed-encryption).\n\nTo learn how to use CMEKs created by\nCloud KMS Autokey to protect your BigQuery resources,\nsee [Using Autokey with BigQuery\nresources](/kms/docs/create-resource-with-autokey#bigquery-autokey).\n\n\u003cbr /\u003e\n\nEncryption of individual values in a table\n------------------------------------------\n\nIf you want to encrypt individual values within a BigQuery table,\nuse the Authenticated Encryption with Associated Data (AEAD) [encryption\nfunctions](/bigquery/docs/reference/standard-sql/aead_encryption_functions). If you want to keep data for all of your own customers in a\ncommon table, use AEAD functions to encrypt each customers' data using a\ndifferent key. The AEAD encryption functions are based on AES. For more\ninformation, see [AEAD Encryption Concepts in GoogleSQL](/bigquery/docs/aead-encryption-concepts).\n\nClient-side encryption\n----------------------\n\nClient-side encryption is separate from BigQuery encryption at\nrest. If you choose to use client-side encryption, you are responsible for the\nclient-side keys and cryptographic operations. You would encrypt data before\nwriting it to BigQuery. In this case, your data is encrypted\ntwice, first with your keys and then with Google's keys. Similarly, data read\nfrom BigQuery is decrypted twice, first with Google's keys and\nthen with your keys.\n| **Important:** BigQuery does not know if your data has already been encrypted client-side, nor does BigQuery have any knowledge of your client-side encryption keys. If you use client-side encryption, you must securely manage your encryption keys and all aspects of client-side encryption and decryption.\n\nData in transit\n---------------\n\nTo protect your data as it travels over the Internet during read and write\noperations, Google Cloud uses Transport Layer Security (TLS). For more\ninformation, see [Encryption in transit in Google Cloud](/security/encryption-in-transit).\n\nWithin Google data centers, your data is encrypted when it is transferred\nbetween machines.\n\nWhat's next\n-----------\n\nFor more information about encryption at rest for BigQuery and\nother Google Cloud products, see\n[Encryption at rest in Google Cloud](/security/encryption/default-encryption)."]]
