как настроить клиентскую библиотеку предотвращения потери данных Google Cloud Platform для Python для работы через прокси-сервер SSL?

Я пытаюсь использовать клиентскую библиотеку Google Cloud Platform Data Loss Prevention (DLP) для Python, работающую через прокси-сервер SSL: https://cloud.google.com/dlp/docs/libraries#client-libraries-usage-python

Я использую фрагмент кода из документа:

# Import the client library
import google.cloud.dlp
import os
import subprocess
import json
import requests
import getpass
import urllib.parse

import logging

logging.basicConfig(level=logging.DEBUG)

# Instantiate a client.
dlp_client = google.cloud.dlp.DlpServiceClient()

# The string to inspect
content = 'Robert Frost'

# Construct the item to inspect.
item = {'value': content}

# The info types to search for in the content. Required.
info_types = [{'name': 'FIRST_NAME'}, {'name': 'LAST_NAME'}]

# The minimum likelihood to constitute a match. Optional.
min_likelihood = 'LIKELIHOOD_UNSPECIFIED'

# The maximum number of findings to report (0 = server maximum). Optional.
max_findings = 0

# Whether to include the matching string in the results. Optional.
include_quote = True

# Construct the configuration dictionary. Keys which are None may
# optionally be omitted entirely.
inspect_config = {
    'info_types': info_types,
    'min_likelihood': min_likelihood,
    'include_quote': include_quote,
    'limits': {'max_findings_per_request': max_findings},
}

# Convert the project id into a full resource id.
parent = dlp_client.project_path('my-project-id')

# Call the API.
response = dlp_client.inspect_content(parent, inspect_config, item)

# Print out the results.
if response.result.findings:
    for finding in response.result.findings:
        try:
            print('Quote: {}'.format(finding.quote))
        except AttributeError:
            pass
        print('Info type: {}'.format(finding.info_type.name))
        # Convert likelihood value to string respresentation.
        likelihood = (google.cloud.dlp.types.Finding.DESCRIPTOR
                      .fields_by_name['likelihood']
                      .enum_type.values_by_number[finding.likelihood]
                      .name)
        print('Likelihood: {}'.format(likelihood))
else:
    print('No findings.')

Я также установил следующую переменную ENV:

GOOGLE_APPLICATION_CREDENTIALS

Он работает без проблем, когда вы не используете прокси-сервер SSL. Когда я работаю за прокси, я настраиваю 3 переменные ENV:

REQUESTS_CA_BUNDLE
HTTP_PROXY
HTTPS_PROXY

При такой настройке другие библиотеки Python клиента GCP отлично работают за прокси-сервером SSL, например, для хранилища или bigquery).

Для библиотеки python DLP Client я получаю:

E0920 12:21:49.931000000 24852 src/core/tsi/ssl_transport_security.cc:1229] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
DEBUG:google.api_core.retry:Retrying due to 503 Connect Failed, sleeping 0.0s ...
E0920 12:21:50.927000000 24852 src/core/tsi/ssl_transport_security.cc:1229] Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed.
DEBUG:google.api_core.retry:Retrying due to 503 Connect Failed, sleeping 0.0s ...

Я не нашел в документации объяснения, работает ли библиотека с прокси в качестве одной клиентской библиотеки GCP и как настроить ее для работы с прокси SSL. Библиотека находится в стадии бета-тестирования, поэтому может оказаться, что она еще не реализована.

Кажется, это связано с сертификатом CA и рукопожатием. Нет проблем с тем же ЦС для библиотеки Python BigQuery и Storage Client. Любая идея ?


person Dr. Fabien Tarrade    schedule 20.09.2019    source источник


Ответы (2)


Ваш прокси работает TLS Interception. Это приводит к тому, что библиотеки Google не доверяют сертификату SSL, который предоставляется вашим прокси-сервером при доступе к конечным точкам Google API. Это проблема человека посередине.

Решение состоит в том, чтобы обойти прокси для API Google. В вашей подсети VPC, в которой работает ваше приложение, включите частный доступ Google. Для этого необходимо, чтобы правило маршрутизации VPC по умолчанию все еще существовало (или воссоздать его).

Частный доступ к Google

[ИЗМЕНИТЬ после комментариев ниже]

Я добавляю этот комментарий, чтобы напугать пчелиный воск.

Перехват TLS настолько опасен, что ни одна разумная компания не будет его реализовывать, если прочитает следующее.

Сценарий в этом примере. Я ИТ-специалист, отвечающий за корпоративный прокси. Компания внедрила перехват TLS, и я контролирую прокси. У меня нет доступа к ресурсам Google Cloud для моей компании. Я очень умен и хорошо понимаю Google Cloud IAM и OAuth. Я собираюсь взломать свою компанию, потому что, возможно, я не получил повышения (придумывайте свою причину).

Я жду, пока один из менеджеров, у которого есть права на уровне владельца / редактора организации или проекта, аутентифицируется в Google Cloud. Мой прокси-сервер регистрирует заголовки, текст и ответы HTTPS для всего, что идет на https://www.googleapis.com/oauth2/v4/token и еще несколько URL-адресов.

Возможно, прокси-сервер хранит журналы в Google Cloud Bucket или на томе SAN без надежной авторизации. Возможно, я просто инженер-программист, который находит файлы журналов прокси-сервера, лежащие или легко доступные.

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

Для сомневающихся изучите мой проект Golang, в котором показано, как сохранять токены доступа OAuth и токены обновления в файл для любой учетной записи Google, используемой для аутентификации. Я могу забрать этот файл домой и авторизоваться без аутентификации. Этот код воссоздает токен доступа по истечении срока его действия, предоставляя мне почти вечный доступ к любой учетной записи, для которой эти учетные данные авторизованы. Ваши внутренние ИТ-ресурсы никогда не узнают, что я делаю это за пределами вашей корпоративной сети.

Примечание. Ведение журнала Stackdriver Audit может фиксировать IP-адрес, однако удостоверением будут учетные данные, которые я украл. Чтобы скрыть свой IP-адрес, я пошел в Starbucks или публичную библиотеку в нескольких часах езды от дома / работы и делал там свои дела. А теперь выясните, где и кто для этого хакера. Это вызовет изжогу у судебно-медицинского эксперта.

https://github.com/jhanley-com/google-cloud-shell-cli-go

Примечание. Эта проблема не связана с Google OAuth или Google Cloud. Это пример проблемы безопасности, которую развернула компания (перехват TLS). Этот стиль техники будет работать практически для всех известных мне систем аутентификации, не использующих MFA.

[КОНЕЦ РЕДАКТИРОВАНИЯ]

person John Hanley    schedule 20.09.2019
comment
почему он отлично работает с библиотеками BigQuery и Storage Client? В этом случае мне пришлось указать сертификаты CA и информацию о прокси в переменных env. К сожалению, что касается вашего предложения, маршрутизация VPC по умолчанию была удалена по соображениям соответствия. Я попробую отключить рукопожатие, чтобы посмотреть, что произойдет. - person Dr. Fabien Tarrade; 20.09.2019
comment
Я не уверен, так как не пробовал анализировать библиотеки Google на перехват TLS. Я скажу, что то, что вы пытаетесь сделать, является проблемой для библиотек Google, и я не думаю, что Google поддерживает перехват TLS. Тот факт, что он работает для BigQuery и Storage, указывает на ошибку (с точки зрения безопасности), которую вы можете исправить в будущем, как только Google прочитает эту ветку. - person John Hanley; 20.09.2019
comment
Одна из возможных причин работы BigQuery и Cloud Storage заключается в том, что их библиотеки используют HTTP для транспорта. Так было в начале 2018 года, и мне нужно подтвердить, что это все еще так. Если вы посмотрите журналы прокси, вы сможете определить, какой протокол (HTTP или HTTPS) использует клиентская библиотека. - person John Hanley; 20.09.2019
comment
Я не эксперт по прокси. Я считаю, что некоторые библиотеки Google отлично работают с перехватом TLS, если вы предоставите необходимую информацию о прокси и файл сертификата CA. Например, если отбросить REQUESTS_CA_BUNDLE, то клиентские библиотеки BigQuery и Storage GCP не работают: TransportError: HTTPSConnectionPool (host = 'oauth2.googleapis.com', port = 443): Превышено максимальное количество повторных попыток с url: / token (вызвано SSLError ( SSLError (неправильное рукопожатие: ошибка ([('процедуры SSL', 'tls_process_server_certificate', 'ошибка проверки сертификата')],),),)), как и ожидалось. Может, я вас плохо понял. - person Dr. Fabien Tarrade; 22.09.2019
comment
@ Dr.FabienTarrade - я не потратил время на исследование перехвата TLS с помощью библиотек Google Cloud API. У меня большой опыт в области безопасности, и я мог создавать всевозможные проблемы и красть учетные данные, данные и т. Д. В сети, где разрешен перехват TLS. Отсюда и исходят атаки типа "злоумышленник посередине". Я бы не стал, позвольте мне повторить, я бы не подключился к сети, которая использует перехват Proxy TLS и требует от меня установки пакета сертификатов на моем компьютере. - person John Hanley; 22.09.2019
comment
Спасибо за комментарии. Мне нужно их переварить, так как я не эксперт по прокси. То, что я только что узнал от команды DLP: ни google-cloud-bigquery, ни google-cloud-storage не используют gRPC: вместо этого они полагаются на библиотеку запросов для JSON-over-HTTPS. DLP использует gRPC, и все нужно настроить по-другому. - person Dr. Fabien Tarrade; 26.09.2019
comment
@ Dr.FabienTarrade - Спасибо за обновление. Я много работаю с gRPC, так как многие API Google их используют. Я не тестировал gRPC и прокси. Учитывая, что основной целью DLP является обработка и обнаружение конфиденциальной информации, использование Intercept Proxy действительно будет проблемой для вас как с точки зрения безопасности, так и с точки зрения реализации. - person John Hanley; 26.09.2019

Резюме:

  1. Клиентская библиотека предотвращения потери данных для Python использует gRCP. google-cloud-dlp используют gRPC, в то время как google-cloud-bigquery и google-cloud-storage полагаются на библиотеку запросов для JSON-over-HTTPS. Поскольку это gRPC, необходимо настроить другую переменную env:

    GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=path_file.pem  
    # for debugging
    RPC_TRACE=transport_security,tsi  
    GRPC_VERBOSITY=DEBUG
    

    Более подробную информацию и ссылки можно найти здесь ссылка

  2. Это не решает всех проблем, потому что он продолжает давать сбой после рукопожатия (прокси TLS), как описано здесь ссылка. Как хорошо объяснил @John Hanley, мы должны вместо этого включить Private Google Access, что является рекомендуемым и безопасным способом. Этого еще нет в сетевой зоне. Я использую API, поэтому команда прокси добавила обход SSL, и теперь он работает. Я жду enbale Private Google Access, чтобы иметь чистую и безопасную настройку для использования API GCP.
person Dr. Fabien Tarrade    schedule 29.09.2019