У меня хостинг-провайдер, в штате шесть человек. Когда я говорю, что мы внедрили СЭД, знакомые ржут: вам-то зачем, вас на одну переговорку хватит.

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

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

Учет доступов в IT-компании начинается не с людей, а с систем

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

Теперь считаем, к чему прикасается только один человек за месяц. Биллинг. Панель виртуализации. Ноды по SSH. Клиентские панели. DNS и кабинет регистратора. Мониторинг. Тикеты. Корпоративный VPN. IPMI на железе. Пропуск в стойку, если речь про colocation.

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

Гугл-таблица, в которой мы заблудились втроем

Сначала я был естественно горд собой. Завел таблицу, все красиво: сотрудник, система, дата выдачи, кто согласовал. Покрасил заголовки, настроил фильтры, красота.

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

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

Если полезть в открытые данные, выяснится: примерно в 40% компаний права уволенных так и остаются живыми. Меня это не утешило. От знания, что я не один такой, работать спокойнее не стало.

Безопасность корпоративных данных — это не только риски, но еще и деньги

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

Добавьте прикладную вещь. Клиенты последние пару лет спрашивают, кто конкретно у меня ходит на их серверы и как эти права снимаются. Раньше я отвечал в духе «у нас маленькая команда, все свои». Ответ так себе: в переводе на человеческий он означает «я не знаю, но вы не волнуйтесь».

Почему не IdM: у меня нечего к нему подключать

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

Полез, конечно. Класс решений называется IdM или IGA, на рынке есть и Solar inRights, и Avanpost IDM, и еще с десяток. Работают они по одному принципу: система через коннекторы ходит в ваши каталоги и приложения и сама создает, меняет и блокирует там учетки. Если у вас Active Directory, почта, СRM и десяток корпоративных приложений с нормальным API — вещь незаменимая.

А теперь мой парк. Панель виртуализации. Биллинг. Кабинет регистратора доменов. Полдесятка клиентских панелей. IPMI на железках. Готовых коннекторов к этому хозяйству нет, и я сильно сомневаюсь, что они появятся: рынок IdM живет банками и корпорациями, а не хостингами на шесть человек. Значит, писать интеграции пришлось бы самому, а это работа не на вечер.

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

Плюс я в какой-то момент понял, что мне вообще не автоматизация выдачи нужна была. Руками завести учетку админу — это две минуты, проблема не в этом. Проблема в том, что через полгода никто не может сказать, кто разрешил и на каком основании. Мне нужно было не «нажми кнопку и раздай», а «покажи документ, по которому этот человек получил права». А документ, согласование и подпись — это ровно то, чем занимается СЭД.

Так что заход со стороны документооборота — не потому что я не нашел ничего умнее. Просто в компании моего размера основание важнее автоматики.

Как я выбирал СЭД для ИТ-компании

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

1С:Документооборот отвалился первым. Система мощная, спорить не буду, но продуктов 1С у меня нет ни одного. Разворачивать под них отдельный стек ради согласования договоров и учета доступов на шестерых значит открыть новый проект вместо того, чтобы закрыть старый. Ценник вышел немалый только за лицензии, плюс внедрение итд.

Искал я дальше так: вбил в поиск «аналоги 1С:Документооборот». Дальше пошли варианты, которые продаются как электронный документооборот для малого бизнеса. Тут я слегка потерялся и перестал понимать логику рынка: функционально проще, а просят как то чересчур много. Не знаю, кто это покупает.

Если смотреть шире, рынок к 1С не сводится. Смотрел также в сторону популярной Битрикс24 - она закрывает согласование внутри портала для совместной работы. ELMA365 это платформа, где моделируется процесс любой кривизны. Jet form сделан по no-code-принципу и рассчитан на настройку без разработчиков. Первые две мощнее по функционалу, тут без вопросов, но внедрение СЭД такого класса подразумевает бюджет и живого человека, который систему ведет.

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

Разграничение прав доступа сотрудников: как я раздавал роли

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

getent group | grep -E 'sudo|wheel|docker'

for h in $(cat hosts.txt); do echo -n "$h: "; ssh $h "wc -l < ~/.ssh/authorized_keys"; done

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

Главная механика, ради которой все затевалось, выглядит скучно. Заявку на создание учетной записи невозможно открыть, пока не залит подписанный договор, трудовой или подряда. Не «не рекомендуется», а физически не откроется. Дальше согласование у техдиректора, задача в работу, закрытие. Отказ тоже фиксируется, со всеми комментариями.

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

Увольнение: как СЭД для небольшой компании экономит мне кучу времени

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

for h in $(cat hosts.txt); do

  echo "=== $h ==="

  ssh $h "grep -l 'ex-admin' /home/*/.ssh/authorized_keys 2>/dev/null; id ex-admin 2>/dev/null"

done

А раньше отзыв доступа при увольнении выглядел бы так. Открываю блокнот как у продавщицы в сельпо, вспоминаю: терминалка, VPN, панель. Иду в общий чат спрашивать, кому там я что раздавал, и ищу по ключам по поиску. Двое отвечают, третий в отпуске. К понедельнику список закрыт процентов на дай Бог семьдесят, а оставшиеся тридцать я не найду никогда, потому что не помню об их существовании, так как давал между делом.

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

Что автоматизация документооборота не закрывает

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

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

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

Пробежимся по итогам

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

Не покупайте инструмент под название проблемы. У меня проблема называлась «доступы», а решалась документооборотом, потому что мне нужно было основание, а не автоматизация.

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

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

Теперь мне интересно про вас. Чем ведете учет доступов в IT-компании и что всплывало на первой ревизии? Отдельный вопросик к тем, у кого команда меньше десяти человек. На каком размере вы поняли, что пора наводить порядок, и поняли ли?