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

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

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

Я использую google-api-client gem (в версии 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 gems. Все, в чем я уверен, это:

  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 gem с файлом ключа JSON, загруженным как для документов - это безопасно?


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

1 Ответ

0 голосов
/ 01 мая 2018

Связь между вашим клиентом и 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. Дайте нам знать, если у вас есть дополнительные вопросы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...