Управление командными паролями несложно, пока в команде трое сотрудников. При 15 сотрудниках оно начинает давать сбои.

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

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

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

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

Почему общий доступ к паролям не масштабируется

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

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

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

Корпоративный менеджер паролей со структурированными хранилищами и групповым доступом заменяет неопределенность контролем: доступ можно осознанно выдавать, проверять и отзывать.

Чем больше становится хранилище, тем меньше пользы оно приносит как средство контроля доступа. Оно может по-прежнему безопасно хранить пароли, но уже не отражает, как на самом деле устроен бизнес, кому принадлежат те или иные учетные данные и кто должен иметь возможность ими пользоваться.

Доступ на уровне команд поддерживает принцип минимальных привилегий

Принцип, лежащий в основе доступа к учетным данным по отделам, прост: у людей должен быть доступ только к тем учетным данным, которые нужны им для работы.

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

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

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

Группы в Proton Pass for Business решают эту задачу: администраторы могут объединять людей в группы, отражающие команды, отделы или проекты, а затем назначать эти группы конкретным хранилищам и элементам, чтобы доступ соответствовал должности, а не списку индивидуальных разрешений.

Структура хранилищ должна соответствовать уровню риска. Именами пользователя с низким уровнем риска легко делиться, а вот учетные данные администратора, финансовые инструменты, системы HR, экспортированные данные клиентов и доступ к резервным копиям требуют более строгого контроля.

Как выглядит правильная структура хранилищ

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

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

  • Финансы: бухгалтерия, расчет зарплаты, банковские сервисы, выставление счетов, налоговые порталы, платежные платформы.
  • Маркетинг: соцсети, аналитика, реклама, управление контентом, инструменты дизайна.
  • Продажи и клиентский сервис: CRM, инструменты для коммерческих предложений, клиентские порталы, платформы поддержки.
  • Операции: порталы поставщиков, инструменты управления проектами, логистика, закупки.
  • ИТ и безопасность: консоли администратора, резервные аккаунты, управление устройствами, DNS, хостинг, инфраструктура.
  • Руководство: материалы для совета директоров, порталы для инвесторов, сервисы уровня руководства, конфиденциальные аккаунты поставщиков.

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

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

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

Цель — не усложнить хранилища. Цель — не смешивать учетные данные с сильно различающимися уровнями риска. Сервис отложенной публикации в соцсетях не должен делить доступ с администрированием расчета зарплаты.

Структуры хранилищ паролей для команд разного размера

Совсем небольшому бизнесу не нужна архитектура хранилищ корпоративного уровня. Слишком сложная структура на раннем этапе может вызвать путаницу и замедлить внедрение.

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

Для команды из 3–10 человек может быть достаточно нескольких широких хранилищ: операции компании, финансы, маркетинг и ИТ. Главное — избегать одного хранилища на все случаи и держать самые чувствительные учетные данные отдельно.

Для команды из 10–50 человек структура хранилищ должна соответствовать реальной организации бизнеса. На этом этапе доступ к учетным данным становится частью повседневных операций: в команды приходят новые люди, подрядчики привлекаются к конкретным проектам, руководители отвечают за инструменты, которыми пользуются их команды, а администраторам нужен способ проверять доступ, не открывая каждую учетную запись по отдельности. Подрядчиков и внешних соисполнителей можно добавлять в хранилища конкретных проектов с ограниченным доступом, чтобы они видели только то, что требуется для их работы, — и автоматически теряли доступ, когда проект завершается.

Для команд от 50 человек и больше — крупных малых и средних предприятий и команд среднего рынка — хранилищам, возможно, придется учитывать как отделы, так и должности. Ярлыка отдела не всегда достаточно: человек может работать в финансах, не нуждаясь в доступе к банковским сервисам, или поддерживать ИТ-операции, не имея привилегированных учетных данных администратора.

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

Как встроить структуру в процесс адаптации

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

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

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

Здесь же помогает и четкая политика паролей. Руководство Proton по созданию политики паролей объясняет, как компании могут определить правила создания паролей, безопасного обмена, управления доступом и аутентификации. Эти правила легче применять, когда учетные данные уже организованы по командам.

Как сделать увольнение сотрудников безопаснее

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

Четко налаженное увольнение выглядит так:

  1. Удалите человека из командных и проектных групп.
  2. Проверьте учетные данные, которыми человек владел или управлял.
  3. При необходимости смените пароли с повышенным уровнем риска.

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

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

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

Более широкая наглядность для администраторов

Правильное управление паролями в команде дает администраторам четкое представление о доступе. Они должны уметь быстро отвечать на базовые вопросы.

Ключевые вопросы о доступе, на которые администраторы должны уметь отвечать

  • Кто может получить доступ к финансовым учетным данным?
  • Какие хранилища доступны подрядчикам?
  • Какие пользователи имеют доступ к паролям администратора?
  • Какими учетными данными делятся разные отделы?
  • Что изменилось после увольнения сотрудника?
  • Какие хранилища содержат рискованные или привилегированные аккаунты?

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

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

Для ИТ-команд Proton Pass for Business поддерживает централизованное управление, политики, безопасный обмен, отчеты и журналы, подготовку пользователей через SCIM и интеграции с SSO. Команды получают централизованный обзор, которого не дают пароли, сохраненные в браузере, и общие электронные таблицы.

Распространенные ошибки в управлении общими хранилищами

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

Пять ошибок становятся причиной большинства провалов с общими хранилищами в растущих компаниях:

Слишком долгое использование одного корпоративного хранилища

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

Зависимость от знаний одного администратора

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

Отношение к доступу к хранилищам как к постоянному

Сотрудники меняют должности, подрядчики завершают проекты, поставщики уходят. Доступ к хранилищам должен меняться вместе с ними.

Игнорирование ротации учетных данных

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

Смешивание повседневных имен пользователя с привилегированным доступом

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

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

Как Proton Pass for Business поддерживает управление паролями в команде

Proton Pass for Business помогает компаниям перейти от неформального обмена паролями к структурированному управлению учетными данными. Команды могут создавать надежные пароли, хранить учетные данные в зашифрованных хранилищах, безопасно предоставлять доступ и управлять корпоративными паролями из одного места.

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

С группами в Proton Pass доступ к учетным данным управляется на том уровне, на котором команды действительно работают: администраторы назначают хранилища и элементы группам, соответствующим их отделам или проектам, а изменения в составе обновляют доступ автоматически — добавление нового сотрудника дает ему всё необходимое; удаление отзывает всё сразу.

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

Организуйте доступ команды к учетным данным с помощью менеджера паролей для бизнеса.