Я ухожу из компании, и у меня слишком много паролей/ключей

Я европейский разработчик программного обеспечения и меняю компанию. Чтобы выполнять свою работу, за годы я получил (от моего начальника и коллег) много неличных общих секретов, таких как:

  • пароли учетных записей root (например, AWS, Google Cloud, Azure, ...)
  • доступ к серверам (пароли и/или ключи SSH)
  • корпоративные учетные данные онлайн-аккаунтов (например, GitHub, платформы электронного обучения, ...)
  • ключи API

Понятно, что любой, у кого есть такая информация, сможет делать неприятные вещи, например, получать доступ к данным клиента или даже удалять корзины S3. Излишне говорить, что что-то подобное было бы огромным для небольшой компании.

Для ясности: я хочу уйти от моего нынешнего работодателя на хороших условиях. Несмотря на то, что мой контракт не требовал от меня периода уведомления об уходе, я предложил остаться на месяц после моего объявления, чтобы подготовить команду (задокументировать вещи, помочь нанять кого-то еще и т. д.). Я даже сказал своему боссу и коллегам, что они могут написать мне после моего ухода, если им понадобится моя помощь.

Мой босс изначально был вполне согласен с моей отставкой; однако в последние несколько дней он начал вести себя со мной странно (холодные приветствия, «забывая» отправить мне копию в некоторых письмах, ...). Может быть, эти вещи только в моей голове, однако я хотел бы защитить себя от любых будущих проблем. Что, если однажды мой коллега случайно уничтожит базу данных? Чтобы защитить себя, стал бы он обвинять меня в том, что у меня есть пароли?

Эти данные доступа хранятся либо в электронной почте моей компании (к которой я потеряю доступ после выхода), либо на моем компьютере (политика «принеси свой собственный ноутбук»), либо в моей учетной записи Google (я использую «сохранить пароль» в Chrome). Это не лучшая практика, но все остальные делают то же самое. Я однозначно почищу свой компьютер/аккаунты после выхода, но не будет никаких доказательств того, что я не распечатывал или не запоминал такие секреты.

И последнее замечание о беспорядке: они не смогут менять ключи/пароли в краткосрочной перспективе (например, на следующий день после моего ухода). Некоторые пароли никогда не менялись с момента создания учетных записей, даже после ухода других сотрудников.

Что бы вы сделали?

Это пароли, которыми все делятся? Или это пароли, относящиеся к вашему идентификатору? То есть вы а) все разделяете учетную запись "admin" и все знают пароль к ней......... или б) у вас есть своя учетная запись "throwaway_admin" и свой пароль, который никто еще знает ? Если учетная запись «throwaway_admin» была удалена в 5:00 во время выхода, этого будет достаточно?
Хороший аргумент в вашу защиту, если это необходимо, заключается в том, что предыдущие уволившиеся также имеют доступ, поскольку пароли никогда не менялись...
@Harper У меня есть множество учетных записей «admin» (например, корневой доступ к учетной записи AWS, корневые SSH-ключи серверов, ключи API) и несколько учетных записей «на мое имя» (например, учетная запись AWS IAM). Моя проблема касается первого типа секретов, было бы легко удалить / деактивировать отдельные учетные записи в мой последний день перед моим боссом. Спасибо!
@SolarMike вы правы, тем более что в моей стране такого рода уголовное преступление носит личный характер, поэтому в суде должны доказать, что гипотетическое ведро S3 было удалено мной. Я не хочу переходить к делу, чтобы доказать, что я не придурок!
Что касается «случайно уничтоженной базы данных» или любых подобных проблем: если ваш администратор базы данных или штатный ИТ-специалист стоит своих денег, все клиентские соединения и операции, включая сведения о том, кто, где и когда, будут в любом случае храниться в журнале, чтобы будет трудно обвинить вас, если только вам не удастся обойти их брандмауэры и удаленно скомпрометировать и захватить их систему и очистить даже журналы маршрутизаторов и брандмауэров;)

Ответы (10)

Что бы вы сделали?

Я бы составил список всех этих логинов и предложил бы помочь тому, кому поручили изменить их все. По мере того, как каждое изменение пароля выполнялось (другим человеком с использованием неизвестных мне паролей), я вычеркивал его из списка.

В течение моего последнего месяца я отправлял обновленный список с каждым из моих еженедельных отчетов о состоянии, а затем окончательный список в мой последний день.

Если бы что-то осталось неизменным, я бы успокоился, зная, что дал им месяц вместе со всем необходимым для выполнения работы.

Это разумный ответ, но он недостаточно защищает увольняющегося сотрудника. Throwaway боится не того, что компания столкнется с нарушением безопасности после его ухода, а того, что они столкнутся с нарушением безопасности и возложат вину на него . Throwaway хочет продемонстрировать, что у него больше нет доступа к защищенным активам компании.
@AIBreveleri: компания решила выдавать своим сотрудникам общие учетные данные вместо использования определенных учетных записей пользователей, которые можно отключить по отдельности. Это на них, а не на ОП. Если OP просто предупреждает компанию заблаговременно до даты их отъезда, что пароли для этих учетных данных (перечисленных OP) необходимо изменить; этого достаточно, чтобы покрыть OP. Если пароли не были изменены, компания несет ответственность за последствия неизменения этих паролей. Ответ Джо уже содержит больше усердия, чем (минимально) требуется для прикрытия ОП, этого недостаточно.
Пусть они будут подписаны, поскольку пароли изменены с оригинала.
В некотором смысле это заходит слишком далеко, и все же недостаточно далеко, ИМО. Я бы предоставил документ со списком, указав, что «<сотрудник> приложит все усилия для очистки менеджеров паролей от вышеупомянутых учетных данных и что <работодатель> не будет возлагать на <сотрудника> ответственность за последующую утечку или использование вышеупомянутых учетных данных. "... попросите юриста просмотреть его, а также <сотрудника> и <работодателя> подписать его. (В КРОВИ) ... в этот момент оставь на усмотрение работодателя, представляют ли учетные данные риск как есть, но прикрой свою задницу.
Или, по крайней мере, убедитесь, что вы написали письменное заявление о том, что вы очистили кредиты от ваших кешей, порекомендовали и надеетесь, что они все будут ротированы после вашего ухода ... И, вероятно, отправить свой личный адрес копию этого электронного письма (возможно, без перечисления учетных записей, для которых у вас были учетные данные).
Это разумный ответ. Ответственность за ИТ-безопасность при уходе из компании не входит в обязанности OP. Хороший ИТ-отдел должен ТОЧНО знать , кто имеет какой доступ, и вносить соответствующие изменения, когда кто-то уходит. Составление списка не обязательно, но свидетельствует о добросовестности.
Я бы добавил приоритет каждого пароля, который можно использовать из Интернета. Знание пароля какого-либо сервера, к которому нет доступа из Интернета, менее критично.

Вы действительно уязвимы для такого рода обвинений. Тем не менее, это отчасти ваш собственный беспорядок, потому что вы до сих пор не использовали передовые методы обеспечения безопасности. Вы это знаете, и я не буду с этим заморачиваться.

Обычно существует три типа модели безопасности для сервис-ориентированного веб-сайта.

  • Один логин (аккаунт/пароль) для корпоративного аккаунта. Ожидается, что все пользователи в компании будут делиться паролем, и любой из них может вызвать хаос. Например, MailChimp.
  • Мастер-аккаунт/пароль для корпоративного аккаунта. Можно просто поделиться этим паролем, но также дают возможность создавать индивидуальные субаккаунты — логин/пароль для каждого сотрудника. Каждое действие регистрируется в его субсчете. PayPal работает следующим образом: мои логины для компании ABC — ABCCo-Harper и ABCCo-HarperAdmin. (Первый предназначен только для точек продаж).
  • Сайт разрешает только учетные записи реальных людей , а затем связывает компании с людьми. Примером может служить бизнес-страница Facebook, где администраторами, участниками или рекламодателями являются любое количество людей.

Серверы в ваших собственных помещениях, безусловно, принимают модель «субаккаунта»; прекратите совместное использование root и настройте учетные записи администратора с помощью sudo.

Распутывая эту скрученную паутину

Слишком поздно делать самое важное: уклоняться от своего пути, чтобы выбрать поставщиков с надежной архитектурой паролей. При настройке наших бизнес-систем я очень избирательно относился к этому; тем не менее, половина наших учетных записей использует общие пароли, потому что очень немногие поставщики поддерживают под-/настоящие учетные записи.

На сайтах «только для реальных учетных записей» сайт уже заставил вас использовать компетентную модель безопасности . Прямо сейчас: убедитесь, что у нужных людей в вашей компании есть учетная запись, и продвигайте их соответствующим образом; по крайней мере один должен быть самого высокого ранга. В последний день: скажите системе, чтобы ваша учетная запись была развязана с активом компании. Очень просто.

На сайтах , поддерживающих отдельные дочерние учетные записи, прямо сейчас : создайте дочерние учетные записи для соответствующих сотрудников вашей компании, включая вас самих, выдайте им пароли и забудьте пароли, которые вы им выдали. Убедитесь, что у соответствующих сотрудников есть мастер-пароль, и попросите их немедленно изменить его. В последний день : уходите и не входите в свою дополнительную учетную запись. Они должны удалить его , но если они этого не сделают, кого это волнует? Журнал системы докажет, что вы ничего не делали.

На всех остальных сайтах сначала убедитесь, что у соответствующих людей правильные пароли.

У вас есть множество паролей, которые не менялись слишком долго. Измените их. Это также относится к любому паролю, который вы сохранили способом, который, как вы знаете, является глупым. Предположим, что он скомпрометирован, измените его СЕЙЧАС и дайте им новый пароль. Сделать это нужно сейчас, пока есть еще месяц на восстановление. Делать это в последнюю неделю слишком поздно.

И убери за собой; как только вы сбросите их, удалите все пароли из мест, где их быть не должно, таких как электронная почта (!), Документы Google и тому подобное. Не уверен, как я отношусь к менеджерам паролей; они далеко не худший и не самый плохой способ справиться с этим.

И не устраивайте новых беспорядков; если кто-то просит пароль, не отправляйте его по электронной почте/твиттеру/мессенджеру Facebook. Перестань. Запишите это на бумаге, запечатайте в конверт и передайте им. Физическая безопасность - их проблема. Или позвоните им по телефону и прочитайте им.

Распространение новых паролей

Я имею дело с остроконечными технофобами , поэтому пароли делаю на бумаге. Я делаю документ MS-Word, в котором перечислены все учетные записи, и ABCDEFG, где будут храниться пароли. Его можно распространять в электронном виде. Затем у меня есть еще один лист, на котором написано просто ABCDEFG с пробелом для пароля для каждого, и я доставляю его вручную. Для остроконечных менеджеров, которые вряд ли будут их использовать, я положил мастер-пароли в конверт с надписью «Мастер-пароли! Не открывать, кроме как в экстренных случаях».

Что касается генерации паролей, то у меня наконец-то закончились диски AOL :) Поэтому я использую обрывок perl и /usr/lib/dict/words для генерации пароля типа CorrectHorseBatteryStaple , настроенного для работы на большинстве сайтов и удобного для мобильных устройств ( т.е. вы не вводите сдвиги больше, чем символы).

Заставьте их сбросить позади вас

При передаче им новых паролей отправьте отдельное электронное письмо с профессиональным уведомлением о том, что вы изменили пароли, список учетных записей, для которых вы изменили пароли, и укажите, что вы предоставили список паролей на бумаге (или каким-либо образом). Копируйте это на свой личный адрес электронной почты за пределами офиса и отправляйте скрытую копию своему юристу . Само собой разумеется, что это электронное письмо НЕ должно содержать никаких паролей .

Затем, при выходе, отправьте им еще одно электронное письмо таким же образом, напомнив им, что вы покидаете компанию по состоянию на дату/время, и, пожалуйста, измените общие пароли позади вас. Опять же, CC для вашего личного и BCC для вашего адвоката.

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

Надеюсь, если вы сделаете то, что я говорю, вы «подогреете» их к идее время от времени менять свои пароли. Они тоже знают, что им нужно это сделать; вы просто сделали тяжелую работу для них.

Теперь зачислите союзника в компанию для сброса паролей за вами.

Ни при каких обстоятельствах НЕ входите в учетную запись, «чтобы узнать, изменили ли они пароль». Каким бы любопытным вы ни были! У вас даже не должно быть больше паролей; вы должны были удалить их везде, где вы храните пароли. Будьте тщательны. Конечно, если будет судебный процесс, они вызовут в суд ваш ноутбук и список учетных записей из 1password и т. Д. Если они покажут, что вы сохранили пароли, это подорвет вашу защиту, что это были не вы.

Спасибо за время, потраченное на написание такого хорошего ответа. Я думаю, что это сработает для большинства людей в моем положении. У меня все еще проблемы, потому что у меня осталась всего 1 неделя, и изменение какого-либо пароля/ключа было бы настоящим PITA (из-за плохой практики, установленной до моего приезда, например, ключ API может быть разделен между несколькими службами, никто не помнит какие, давайте поменяй и посмотри что сломается) Другой мой страх: если я попрошу их изменить все, что я знаю, заподозрят ли они (поскольку ни у кого нет четкого списка всех учетных данных компании!), что я планирую сделать что-то гадкое с забытыми (неизмененными) секретами?
Я действительно сомневаюсь, что они сделают вывод о злом умысле. Они воспримут это как шаг CYA, а это именно то, что есть!, и, вероятно, проигнорируют вас. Вам просто нужно выполнить свою часть передачи пароля как можно ответственнее и оставить бумажный след, который вы сделали. Таким образом, у вас есть этот бумажный след, чтобы размахивать им в суде, если возникнет спор. Или, наоборот, вы уходите, они идут куда попало, *кого-то еще увольняют, и они говорят: «Черт возьми, этот парень сотрет нас с лица земли, где все эти одноразовые записки, которые нам дали?»
@throwaway также, безопасность всегда неудобна. Природа зверя. Плохая подготовка делает это намного более неудобным, и это проблема, с которой они сталкиваются сегодня.

Как ИТ-менеджер с более чем 20-летним стажем работы, я могу сказать вам, что вам не нужно ничего делать. Надлежащая ИТ-безопасность означает, что отдел должен иметь записи о том, какие пользователи или приложения имеют доступ к тем или иным ресурсам. Когда кто-то уходит, или проводится аудит, или просто меняются пароли/ключи/и т. д. по расписанию, на эти записи следует ссылаться и обновлять. К сожалению, не каждый ИТ-отдел делает это, что делает их неосознанно уязвимыми.

Хотя это и не обязательно, составление списка всего, к чему у вас есть доступ, показывает добросовестность вашей компании. Возможно, было бы неплохо предложить им инвестировать в надлежащую систему контроля паролей.

Во-первых, я бы определил людей/человека, которые возьмут на себя вашу роль. Если вы не можете найти этого человека, сделайте его своим менеджером.

Откройте корпоративную учетную запись LastPass (другой безопасный вход в систему, оплачиваемый непосредственно компанией. Пригласите себя и своего нового человека в учетную запись. Добавьте все данные для входа, которые вы защитили (небезопасно) в своем электронном письме.

Любые логины, которые привязаны напрямую к вам — измените их, чтобы они использовали корпоративные реквизиты. Например, вместо того, чтобы регистрироваться как «fred.bloggs@example.com», используйте «systems@example.com» — это может привести к списку рассылки.

Когда вы добавляете удостоверения в lastPass, удалите их из любой системы, к которой вы сможете получить доступ после выхода. Также отключите любые личные данные для входа (например, ваши учетные записи пользователей AWS — НЕ удаляйте учетные записи пользователей root :)), как только вы поймете, что они вам больше не понадобятся.

Записывайте в Excel все внесенные изменения (например, «Учетная запись AWS 123456 — пароль изменен для Fred Bloggs» — не добавляйте туда никакой секретной информации). Передайте эту запись своему менеджеру, когда будете уходить, отсоедините свою личную учетную запись от LastPass (если она была связана с корпоративной учетной записью) и отправьте электронное письмо своему менеджеру с настоятельным предложением изменить мастер-пароль LastPass и все учетные записи в нем.

Как сказал кто-то ранее; не пытайтесь войти в какие-либо учетные записи, «чтобы узнать, был ли изменен пароль». Вы не хотите, чтобы какие-либо записи аудита ваших доступов появлялись после того, как вы ушли.

Я бы предпочел локальное решение, такое как KeePass2, вместо того, чтобы передавать пароли стороннему сервису, такому как LastPass.

Когда вы находитесь в таком критическом положении, профессиональная вещь, которую нужно сделать, — это составить документ/руководство по передаче для того, кто сменит вас на этой должности.

Это будет включать любые знания, относящиеся к роли, пошаговые процедуры для чего-либо важного или конкретной работы, а также раздел, включающий имена пользователей и пароли.

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

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

Что бы вы сделали? Заранее спасибо!

Ничего не делать. Если у вас все еще есть возможность войти в любую учетную запись после вашего последнего дня, не делайте этого! Да, компания может столкнуться с каким-то нарушением безопасности, и вас могут обвинить, но пока вы перестанете входить в эти учетные записи, не будет никаких доказательств правонарушений с вашей стороны.

Если вы ушли в хороших отношениях, они не должны даже считать вас подозреваемым, если произойдет какое-либо нарушение безопасности. Я оставил компании с такой привилегированной информацией и имел самообладание, чтобы не пытаться использовать ее. Сделайте то же самое, и вам не о чем будет беспокоиться.

Прежде чем дать рекомендацию, уточним несколько моментов:

Ожидается, что когда вы уйдете, вы больше не будете иметь доступ к сети вашей компании, как правило, через руководство для сотрудников, соглашение о неразглашении и т. д.... какое-то соглашение, если оно отсутствует. тупица вашего работодателя b. вы по-прежнему не должны получать доступ к сети из соображений этики.

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

Теперь, если вы хотите быть милым... создайте документ или еще лучше файл Keepass и поделитесь им. Вы можете проверить Keepass в источнике.

Возможно, для этого уже слишком поздно, но если вы сможете или в будущем, используйте такую ​​технологию, как Active Directory/LDAP, с централизованным хранилищем ключей. Настройка вашей компании - это спагетти.

Сейчас лучше всего передать все кому-то другому. Если возможно, им следует обновить все пароли, ключи и секреты и поместить их в хранилище ключей за защитой.

С такими технологиями у вас будет централизованный набор пользователей, ролей, групп и разрешений. В правильной экосистеме, такой как Active Directory с Azure Key Vault, все секреты могут быть централизованы и скрыты за политикой, определяющей правильный набор разрешений.

Кроме того, например, вы можете использовать Active Directory практически для всего. Электронная почта, среда Azure, логины сервера и т. д. Все это учетная запись домена, и все всегда скрыто одним: вашим логином домена. Это элегантно.

Когда сотрудник уходит с рабочего места, его учетная запись просто отключается, а значит, и его доступ ко всем ключам и секретам тоже отключается. Их доступ ко всем серверам, системе управления версиями или облачной среде отключен. Это очень чисто. Просто нужна правильная бизнес-архитектура. Некоторые инструменты миграции могут существовать, но перемещение всех ключей может привести к беспорядку, в зависимости от того, как вы их сохранили (Excel, блокнот, салфетки и т. д.).

Вам не нужно ничего делать. В правовой системе существует стандарт «невиновен, пока не доказана вина». Это означает, что если у них есть нарушение безопасности и они обвиняют в этом вас, они должны доказать в суде, что вы были тем, кто взломал их, используя ваши учетные данные. Что, учитывая их спагетти безопасности, они, вероятно, не смогут сделать, даже если вы их взломаете, поэтому юридически вы, вероятно, ни за что не отвечаете (IANAL).

Профессионально вам следует сказать им: «Это то, к чему, как я знаю, у меня есть доступ» (у вас может быть доступ к другим вещам, о которых вы не знаете/забыли) и перечислить как можно больше из них. Затем отправьте это письмо своему начальнику и/или в отдел информационной безопасности вашей компании. После этого вы мало что можете сделать; их работа — отозвать ваши разрешения и убедиться, что у вас нет доступа после того, как вы уйдете. Если они решат этого не делать, это будет на их совести, а не на вашей. Что касается вашей ответственности, с этической (а также, вероятно, с юридической точки зрения) вы не должны использовать те учетные данные, которые у вас есть, даже если они все еще действительны по какой-либо причине после вашего последнего дня в офисе. Который, я уверен, в любом случае был твоим планом и не нуждался в повторении, но это

В качестве последнего замечания о беспорядке, они не смогут менять ключи / пароли в краткосрочной перспективе (например, на следующий день после моего ухода). Некоторые пароли никогда не менялись с момента создания учетных записей, даже после ухода других сотрудников.

Это неправильно, это не имеет смысла, и вы должны убедить их изменить эту политику. Это может показаться грубой просьбой, но последствия, если кто-то нанесет ущерб с этими учетными данными и обвинит вас, могут быть намного хуже, чем риск сжечь мосты с компанией.

Я бы написал электронное письмо начальнику, например:

Уважаемый босс, это письмо, чтобы напомнить, что у меня все еще есть доступ к следующим учетным записям: . Поскольку я уезжаю в , я прошу вас принять меры в течение этого периода времени, чтобы изменить учетные данные и передать их другим людям. С наилучшими пожеланиями

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

Кроме того, оба письма BCC направляются вашему адвокату.

«Я предприму юридические действия, чтобы защитить себя». Такой как? Звучит как довольно пустая угроза.
Что ж, пусть начальство решает, хотят ли они рискнуть выяснить, действительно ли это пустая угроза, или они предпочитают просто сменить пароли. Однако, если вы отправите своему адвокату скрытую копию указанных выше электронных писем, вы можете, по крайней мере, продемонстрировать, что просили отвязать вас от учетных записей.
Я думаю, вы, вероятно, не имели в виду притворяться , что является ложным другом некоторых (всех?) романских языков. В английском языке «притворяться» означает действовать так, как будто что-то правда, когда вы знаете, что это не так . Я думаю, вы, вероятно, имели в виду « вы должны попытаться заставить их изменить эту политику ».
@PeterTaylor, ты прав, спасибо. Я перефразировал это.