Как надежно работает шифрование / дешифрование CloudKMS при вызове из системы, не принадлежащей Google?

Мне нужно знать, что plaintext / ciphertext отправка в Google CloudKMS и открытый / закрытый ключ, используемый для аутентификации, безопасны при передаче, но я не знаю, как это доказать.

В соответствии с документами KMS я создал учетную запись службы, загрузил файл ключей JSON и подключил его через переменную среды GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json,

Я использую гем google-api-client (в версии 0.10.3, выпущен 13 месяцев, потому что я не могу установить mime-types >= 3.0 при использовании padrino-mailer: смотрите этот коммит), проверили Google::Apis::CloudkmsV1::CloudKMSService методы encrypt_crypto_key а также decrypt_crypto_key И они работают хорошо.

Я попытался прочитать исходные коды гемов google-api-client, googleauth и signet. Все, в чем я уверен, это:

  1. Файл ключа JSON загружен и private_key значение используется, чтобы сделать OpenSSL::PKey::RSA.new Вот
  2. Signet::OAuth2::Client дается ключ RSA как signing_key в этом файле

Я считаю, что безопасность доказана, если файл ключа JSON используется для шифрования строки, отправленной через encrypt_crypto_key на вызывающем сервере, а также расшифровать строку, полученную decrypt_crypto_key и сервер CloudKMS на другом конце ведет себя аналогичным образом. Это то, что я предполагаю, что библиотека делает - сквозное шифрование - но я должен увидеть это, чтобы поверить в это. Я попытался просмотреть трафик в Wireshark, но не смог понять его смысл (возможно, этот факт доказывает это? Я не знаю)

Может ли кто-нибудь помочь мне доказать или опровергнуть этот метод вызова CloudKMS для шифрования / дешифрования пользовательских данных - использование гема google-api-client с файлом ключа JSON, загруженным в соответствии с документами, - безопасно?

Связанный: для тех из вас, кто интересуется, API CloudKMS находится на пути к включению в новую драгоценность google-cloud.

Источник

1 ответ

Решение

Связь между вашим клиентом и Google защищена через TLS. В Wireshark вы можете видеть, что связь осуществляется через порт 443, и что соединение TLS согласовано.

Ваши запросы аутентифицируются с использованием OAuth. В этом случае (используя учетную запись службы из-за пределов GCP) это выполняется с использованием потока, документированного в разделе Использование OAuth 2.0 для серверных приложений:

  • Вы несете ответственность за предоставление приложению вне GCP закрытого ключа, выданного учетной записи службы, которую вы хотите подтвердить;
  • затем он использует этот закрытый ключ для подписи JWT и отправки его на OAuth-сервер Google;
  • Google отвечает маркером доступа OAuth, который является учетными данными на предъявителя, которые идентифицируют соответствующую учетную запись службы;
  • Затем вы предоставляете этот токен доступа с вашими запросами в KMS, чтобы идентифицировать объект, который отправляет запросы в качестве учетной записи службы и использует свои полномочия;
  • Затем KMS и GCP используют эту идентификацию для оценки контроля доступа IAM, чтобы определить, разрешены ли определенные операции.

Это защищенное сквозное соединение (соединение TLS является сквозной защитой, поскольку стороны связи - ваша служба и Google - являются конечными точками TLS). Поскольку ваш вопрос выглядит так: "Являются ли эти запросы безопасными при передаче и как я могу это показать", я думаю, что достаточно показать, что происходит согласование соединения TLS, Wireshark должна показать вам это. (Ваша библиотека подключений также должна выполнить подходящую оценку PKI представленного сертификата; проверка того, что это происходит правильно, немного сложнее, но разумно доверять тому, что происходит правильно, если вы исследуете инструменты, которые используете и их утверждения о проверке сертификата).

С наилучшими пожеланиями и спасибо за использование GCP и Cloud KMS. Дайте нам знать, если у вас есть дополнительные вопросы.

Источник
Другие вопросы по тегам