Я вошел в общую систему, которой я не владею, и у меня есть доступ к команде gsutil в этой системе.
Я хотел бы использовать gsutil в этой системе для управления некоторыми облачными данными Google (загрузка резервных копий и т. Д.), Но означает ли это, что мне нужно создавать локальные файлы с моими учетными данными или закрытыми ключами в них?
Это меня беспокоит, потому что это не моя собственная система, и я не доверяю этим конфиденциальным учетным данным, хранящимся в общей системе ...
Есть ли способ сохранить учетные данные локально на моем компьютере и запустить gsutil удаленно, например:
ssh user@untrusted.com gsutil бла-бла-бла -C ./my/local/config.key
... так что я храню ключи / кредиты локально и запускаю gsutil удаленно, через SSH?
Что, если ты сбежишь gsutil auth login в ненадежной системе, чтобы получить учетные данные, выполните другие команды gsutil, а затем завершите сеанс с помощью gsutil auth revoke? Хотя это может оставить что-то, что может смотрю как учетные данные в ненадежной файловой системе, они будут тарабарщиной для Google; они не будут действительны для аутентификации.
Этот сценарий предполагает: (а) что ненадежная система gsutil команда и библиотеки заслуживают доверия (например, они не будут пытаться кэшировать ваши учетные данные в другом месте) и (б) что корневая учетная запись ненадежной системы не пытается активно отслеживать ваши учетные данные gsutil во время сеанса. Окно уязвимости, то есть поверхность вашей атаки, ограничено периодом времени между auth и revoke команды.
Другой вариант - создать и смонтировать зашифрованную файловую систему FUSE, но поверхность атаки такая же: пока вы используете gsutil команда для выполнения работы, она использует ваши действительные учетные данные, поэтому ваша экспозиция такая же. Если на то пошло, даже если вы могли бы передать учетные данные через сокет или именованный канал через ssh-соединение с gsutil , если gsutil был изменен для захвата ваших учетных данных, вы уязвимы, пока учетные данные не будут отозваны.
Я знаю, что это расширяет рамки вашего вопроса, но знать, какие векторы атаки вас беспокоят, может помочь нам найти решения, позволяющие снизить ваши опасения. Просто назвать систему «ненадежной» может означать много разных вещей.