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

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

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


person yopangboy    schedule 03.06.2019    source источник
comment
Если вы используете ключи, управляемые Google (рекомендуется), ротация ключей будет выполняться за вас. Данные всегда передаются в зашифрованном виде. Так что и тебе там делать нечего.   -  person Lak    schedule 03.06.2019
comment
Всем привет! Добро пожаловать в SO. Это очень широкий вопрос. Однако Лак прав. Позвольте Google позаботиться о ключах за вас. Они сделают работу намного лучше. Однако если вы действительно хотите, вы можете управлять своими собственными ключами, включать элементы управления службами VPC, использовать функции шифрования AEAD и т. Д. Пользователи не должны использовать учетные записи служб для доступа к BigQuery. Они должны быть только для местного развития. Учетные записи служб действительно должны использоваться только для машинных вещей. Предоставьте пользователям доступ, используя свои собственные учетные записи, для надлежащего ведения журнала / аудита / отключения. Назначьте соответствующие IAM / ACL / политики каждому пользователю (используйте группы).   -  person Graham Polley    schedule 04.06.2019
comment
Привет, GrahamPolley & Lak Большое спасибо за ответ! Я буду использовать ключи, управляемые Google. Еще один вопрос относительно учетной записи службы, если кто-то может пролить свет на это: допустим, один из наших специалистов по данным использует свои собственные ключи доступа / секретные ключи для извлечения данных из BigQuery, и процессы автоматизированы с помощью большого количества скриптов. Означает ли это, что, когда он / она покидает компанию, единственные способы сохранить работу скрипта: учетная запись службы имеет больше смысла в этом случае?   -  person yopangboy    schedule 04.06.2019


Ответы (1)


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

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

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

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

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

person ch_mike    schedule 06.06.2019