Какова наилучшая практика безопасности при настройке Google Query?

Question

У меня был некоторый опыт работы с AWS, но он был совершенно новым для облачной платформы Google, особенно для Google Big Query. Я прочитал много документации, но меня немного смутило и ошеломило количество информации. Если я хочу настроить большой запрос, который будет использоваться для подключения к нескольким сторонним платформам. (который использует большой запрос в качестве соединителя) С точки зрения безопасности (со стороны сети), какую рекомендацию следует придерживаться, чтобы убедиться, что данные находятся в безопасности при передаче?

Я уже настроил служебную учетную запись, которая имеет доступ только к Большому запросу. Я буду назначать пользователям, которым нужен большой запрос, доступ к роли «пользователь учетной записи службы». Из того, что я прочитал, ключ учетной записи службы будет автоматически вращаться каждые две недели. Означает ли это, что разъем будет ломаться каждые две недели? Если так, есть ли лучший способ сделать его постоянным? При настройке проекта также используется VPC по умолчанию. Существуют ли какие-либо услуги, предоставляемые платформой Google Cloud, которые я должен знать, чтобы сделать ее более безопасной?

Answer 1

Я постараюсь обобщить то, что вы обсуждали до сих пор, и ответить на ваш последний вопрос: по умолчанию данные шифруются как в покое, так и в пути с использованием управляемых ключей Google. Это рекомендуемая установка, поскольку вы избегаете сложности и ваши данные в безопасности.

Учетные записи пользователей ( Учетные записи Google ) предназначены для разработчиков: людей, которые будут устанавливать ключи шифрования, если вы решите использовать управляемые клиентом ключи шифрования (CMEK) и которые будут взаимодействовать «Вручную» с BigQuery, обычно через пользовательский интерфейс или инструмент командной строки.

Сервисные учетные записи , как упоминал Грэм, предназначены для машин, поэтому сценарии и автоматизированные компоненты должны запускаться с учетными записями служб.

CryptoKeys - это ресурсы в GCP, поэтому для них можно и нужно устанавливать политики IAM, поэтому любая учетная запись службы или учетная запись пользователя, взаимодействующая с CryptoKeys, должны иметь надлежащие уровни разрешений. Вы можете увидеть список доступных разрешений здесь . Например, чтобы создать таблицу в BigQuery с ключами, управляемыми клиентом, необходимо предоставить роль Encrypter / Decrypter учетной записи системной службы BigQuery (это учетная запись службы, созданная по умолчанию, и она требуется для правильной работы BigQuery в вашем проекте).

Для решения вашей последней проблемы, если в вашей организации есть как минимум 2 пользователя с соответствующими правами для управления ключами, вам не нужно беспокоиться об уходе сотрудника (плюс, владелец проекта в основном имеет все разрешения по всем ресурсам). Кроме того, владелец проекта и роль cloudkms.admin могут предоставлять разрешения через ключи другим учетным записям пользователей или служб.