Если у вас в организации процессы не построены — то этот текст для вас бесполезен. Если построены — то тоже бесполезен. Почти Rifleman's Creed — Without me, my rifle is useless. Without my rifle, I am useless.
Каких-то стандартных пакетов управления всей архитектурой и техникой я не видел — что не удивительно, учитывая постоянное расхождение отчетности по бухгалтерии и техники по факту и общую сложность систем. Хорошо если ведется схема сети, учет паролей и прочее необходимое, есть какой-то учет что когда (сертификаты, оплата домена) истекает, но порой этого нет. Просто одни забыли спросить, другие не волновались насчет этого. У третьих оно было, но они уже уволились, а четвертые забили, вот и имеем что имеем.
Управление жизненным циклом, SCOM/SCSM — это немного другое, а ITIL
Service Asset and Configuration Management — это благие пожелания, не содержащие некий функционал.
Соответственно, первым делом при приходе на работу нужен аудит «для себя»
— Какие устройства где стоят, за что отвечают, есть ли к ним доступ (к web панели управления/ssh/ilo), если нет — то как его восстановить. Живы ли эти устройства, или стоят для учета.
— Кто ответственный за СКУД, общую безопасность, электричество, кондиционирование (обслуживание), водопроводы, пожарную сигнализацию. Когда последний раз проводилось обслуживание тех же кондиционеров. Какова надежность (запас мощности) кондиционеров (N+0, N+1).
— ИБП и батареи. Сколько держат (в часах), когда менялись батареи, когда была калибровка, есть ли извещение о срабатывании и прочем блекауте. Какова надежность (запас мощности) ИБП — (N+0, N+1).
— Как выстроено взаимодействие с соседними отделами и бизнесом как заказчиком сервисов.
— Как работает сервис деск.
— Как работает мониторинг, мониторит ли он все устройства и необходимые параметры оборудования. Возможно что давно умер или избыточен. Или недостаточен.
— Как работает извещение о сбоях, особенно крупных — например, общий блекаут/отключение электричества, протечка водопровода / отопления.
Архивация и восстановление
Надо проверять все — что куда бекапится, какова глубина хранения, есть ли свободное место на системе хранения архивов, мониторится ли свободное место, попадает ли бекап в окно резервного копирования. Как идет восстановление — как выглядит процедура восстановления и вообще восстанавливается ли.
От имени какой УЗ идет архивация (особенно в случае агентов/сервиса бекапа в машинах), не многовато ли у нее прав (в каких группах состоит), есть ли у нее (и от нее) пароль и не стоит ли его сменить. Где она (в системе резервного копирования) прописана.
Есть ли регламент, в котором прописано и утверждено все вышеперечисленное.
Контроль прав, контроль служебных УЗ (учетных записей)
Кроме простой проверки «кто в группе доменных администраторов и почему», необходим контроль служебных УЗ. В том числе контроль какой сервис от какого имени стартует (если не стартует от системы), что со встроенными УЗ, что в какую группу включено и зачем, какие им (группам) делегированы права и куда.
AD
Роли AD — где (на каких серверах) лежат, что в журналах. Кто за какие сетевые сервисы (DHCP, DNS) отвечает. Аудит — есть ли, как устроен. Пересылка логов — каких, куда, и что там с ними происходит.
Готовьтесь изучать новый для вас предмет — инженерная археология / Конструкторско-технологическая археология (1)
Типовые дыры и костыли кривокурих админов локалхоста. Начиная от правленных host
ВНЕЗАПНО для меня выяснилось, что админы локалхоста не только правят файлы etc/host (ну ладно, кто не правил в детстве?), но еще этим и гордятся, и пишут об этом статьи.
Впрочем, с настройками DNS на DC бывает тот же стыд.
Не, ну как можно не прочитать технет?? (2)
ЗАПОМНИТЕ, ГРАЖДАНЕ!
Писать в \host\etc в продакшене надо тогда и только тогда, когда ты уже прочитал инструкцию, для Оракла и Veritas netbackup, дожав инструкциями по Veeam.
Вторая очередь проверки
По приходу на работу, кроме аудита физики (начиная от кондиционеров и срока жизни батарей в ИБП и времени работы ИБП от батарей, заканчивая что и как числится по учету — и что из этого есть по факту) — надо проверять три вещи:
— Задачи в Tash scheduler и автозагрузке по серверам
— файлы HOST в частности и настройки DHCP и DNS в целом
— кому, как, куда и какие даны права в AD и Exchange.
Если с первым пунктом понятно, скачиваем Sysinternals Autoruns for Windows и поехали, то с вторым и третьим пунктом все сложней.
Внезапно для многих, в Microsoft Windows server нет кнопки «сделать хорошо». Даже скрипта makegood.ps1 нет — MS WS и AD как сервис не имеет каких-то встроенных готовых графических решений для отображения кому и куда делегированы права в AD, а использование powershell огорчает инфобезопасника и любителя GUI.
С другой стороны, необходимый инструментарий для этого есть —
Для просмотра делегирования прав по organizational unit (OU) — Active Directory OU Permissions Report:
This script generates a report of all Active Directory OU permissions in the domain. I would advise all Active Directory shops to review this report on a quarterly basis to make sure there are no surprise administrators lurking in your domain.
Лежит традиционно на технете.
Для просмотра раздачи прав Exchanhe вот — на том же технете
RBAC Role Group Membership Reporting
This PowerShell script will generate a report of the Role Based Access Control (RBAC) role groups in an Exchange Server organization.
Для начала аудита всего вышеперечисленного должно хватить, но до его проведения переходить к чтению документов «как сделать хорошо» не стоит, потому что скорее всего придется много раз хвататься за голову.
Ссылки:
(1)
Индустриальная археология «Мценского уезда». Часть 1.
Индустриальная археология «Мценского уезда». Часть 2.
Корпоративная память и обратная контрабанда.
Копия этой же статьи со ссылками.
Оригинал в web.archive
Конструкторско-технологическая археология
(2)
Ссылка 1
Ссылка 2
или
Ссылка 3
и наконец собственно:
DNS: DNS servers on should include the loopback address, but not as the first entry
Impact
If the loopback IP address is the first entry in the list of DNS servers, Active Directory might be unable to find its replication partners. См. по ссылке
Вообще с доступностью первого DNS для CSV есть много интересного, но о этом может быть будет позже.
Комментарии (21)
pascvilant
22.07.2017 19:36+1Нюанс. Перед тем, как начинать ковыряться в мелком барахле, следует сделать то, что в ВУЗах требуют обязательным разделом отчета по производственной практике: сообразить структуру бизнеса (в общих чертах) и структуру подразделений, с предварительным пониманием того какие и через кого вопросы решаются. Отсюда всплывет понимание сервисов, существующих в ИС и понимание разделения полномочий. Хотя бы узнаете у кого спросить почему вот этот сервис бэкапится по такому странному расписанию (к примеру)
Alexeyco
22.07.2017 22:01+1Я бы еще рекомендовал немного вникнуть в то, как «местные» понимают некоторые термины и понятия. К примеру, отказоустойчивость. Везде, где я работал, отказоустойчивостью считалось, грубо говоря, «чтобы сервис не падал». Но есть один работодатель, где под отказоустойчивостью понимается устойчисовть сервиса к падению зависимых систем. К примеру, если повалился redis-сервер, сервис должен оставаться на плаву, но уже без кэша. Именно — не то, что redis-сервер не должен падать и должен быть кластеризован. Пары литров крови мне стоило это понимание.
goral
28.07.2017 20:12«устойчисовть сервиса к падению зависимых систем»
ваш работодатель перепутал отказоустойчивость с живучестью системы (все вокруг упало, а она продолжает работать, хоть и с ограничениями)Alexeyco
29.07.2017 21:40Вообще все сильно сомнительно. Перед тем как «все» повалится оно заберет все ресурсы у всего. В том числе, и у целевой системы. И она рухнет точно так же. Потом — redis (к примеру) тоже же не просто так там забыт. Он облегчает. Если он свалится, нагрузка увеличится в любом случае.
Слава богу, все это уже не актуально.
Alexeyco
22.07.2017 21:57+1Если у вас в организации процессы не построены — то этот текст для вас бесполезен. Если построены — то тоже бесполезен.
Если даже ты пойдешь налево — попадешь на Курский вокзал; если прямо — все равно на Курский вокзал; если направо — все равно на Курский вокзал. Поэтому иди направо, чтобы уж наверняка туда попасть. — О тщета!
© Венедикт Ерофеев, «Москва-Петушки»
merlin-vrn
24.07.2017 09:02Каких-то стандартных пакетов управления всей архитектурой и техникой я не видел — что не удивительно, учитывая постоянное расхождение отчетности по бухгалтерии и техники по факту и общую сложность систем.
Вы слышали про ITIL? Как раз для этого и разрабатывается.
Это набор стандартных практик по управлению инфраструктурой. Есть и «в софте» реализации, например, OTRS — там есть CMDB для инвентаризации всего.Scif_yar
24.07.2017 20:38-1Управление жизненным циклом, SCOM/SCSM — это немного другое, а ITIL
Service Asset and Configuration Management — это благие пожелания, не содержащие некий функционал
OTRS «из коробки» мне покажет нагрузку на ИБП и состояние батарей?merlin-vrn
25.07.2017 09:06нет, это система заявок и учёта, а не мониторинга
Но он, при правильном ведении, покажет дату последней смены батарей и какие вообще там ибп и батареи.Scif_yar
25.07.2017 20:41>> при правильном ведении, покажет дату последней смены батарей
— при правильном и при ведении. Но калибровка нужна.
А так да, если документация есть, то с ней лучше чем без нее
bravo-ej
25.07.2017 03:57+2Жду третьей статьи на тему «что ещё нужно проверять придя на работу/получая повышение»…
Ладно про ITIL могли не слышать… ладно могли слышать, но не было времени осилить (это про меня, собирался собирался, но никак)…
Ну разве сами не догадываетесь, что вместо скомканных советов по тому, с чем именно автор столкнулся, лучше попытаться набросать структуру сущностей, зависящих друг от другу, выстраивая дерево.
Например:
- Электропитание
- Вводы, РЩ, контуры заземления – схемы, ТТХ, регламентные проверки (календарь для этого надо завести), договора, контакты поставщиков и аутсорса, фотографии, система маркировки, ответственный в вашей организации.
- АВР/ЩАП (если есть) – тоже самое + логика работы
- Если вы более или менее крупная организации, или где инфраструктура IT — профиль (оператор какой нибудь) — Регламенты проверок контуров заземления, журналы электробезопасности и, фиг с ним, охрана труда пусть тоже тут будет, сопутствующие журналы по учёту доступа
- Регламенты поверок/замены инструмента/приборов. Тут скорее я про КИП, резиновые ковры, стремянки, перчатки диэлектрические и пр...
- В идеале ещё знать где какой кабеле лежит, что бы иметь на него сертификаты/госты/декларации соответствия, санитарные и пожарные заключения, если имеются
- Кондиционирование
- Документация из набора поставки + гарантийники (даже если кончились) + счёт по которому покупали
- График регламентного обслуживания: два раза в год по-любому чистка и дезинфекция, вам же там дышать этими фильтрами; 1 раз в год (если визуально проблем нет) проверка на утечку хладоносителя; проверки включениями тех кондиционеров, которые стоят для резерва. Дальше нюансы зависящие от возможностей и реализацией кондиционеров.
- Договора, контакты подрядчиков по обслуживанию, ремонту, консультации
- Пожаротушение и вентиляция
- тоже самое, что и с климатом, только без пуска системы конечно :) (снимаем пускатель с баллона/оф и тестируем датчики, градусники, оповещатели и сигнализацию).
- договора, контакты…
- регламенты замены АКБ в блоке управления
- регламенты обслуживания баллонов или, не дай боже, порошковых средств тушения (пенных то по-любому не должно быть, понятно почему я думаю)…
- СКД
- документация на устройства
- документация на сеть
- доступ к менеджменту
- корпоративный регламент. я про то, что бухгалтерия или коммерческий отдел могут считать себя самыми главными, но в технических помещения им делать нечего, так что пусть проваливают. У нас в помещения узлов связи имеют доступ только технический персонал и административный типа технического директора или директора по эксплуатации. (генеральный директор тоже без доступа, но кто ж его не пустит ;)
- договора, гарантии, контакты и т.д…
… это только инженерные системы, которые обычно на аутсорсе или не требуют много знаний для регулярных проверок по чек листам… некоторые пункты требуется разложить ещё глубже, особенно где начинается работа с ПО (дистрибутивы, инструкции, права доступа, ченж лог, хранение учётных данных и т.д). Упороться можно очень глубоко, НО зачем? Всё, что можно добыть сразу после авторизации (за исключением сложных логик и т.п, а например списка пользователей, списка шар, названия портов на коммутаторах) – смысла писать _на бумажке/экселе_ НЕТ. Если у вас есть система сбора конфигов, сислог, мониторинг — другое дело, но там уже и не ручной труд и есть своя систематизация хранения и представления всего этого…
Ну в общем и так далее… по факту, я конечно же понимаю, что кто-то скажет, мол хитрый какой, написал более или менее о конечных сущностях, а как быть с программной и аппаратной инфраструктурами в IT, да ещё и всякими специфичными для отраслей… Ну да, я же для примера. Любая сложная единица инфраструктуры потребует записать огромное количество вложений, которые сами будут являться большими ветками в этом волшебном бобовом дереве… Один мониторинг чего стоит, где надо понять набор сущностей, которые мы хотим мониторить, затем понять интересный нам набор телеметрии этой сущности, как часто каждый из пунктов этого набора мне нужно видеть, строить по ним графики или просто чекать пороговые значения (да и какие эти значения для уведомления), притянуть в мониторинге зависимости, что б не получать 100500 смс на телефон из-за отвала ветки агрегирующего узла сети или типа того…
В общем, систему надо думать, а не описывать ваш героический путь по очистке индивидуального, уникального и требующего героизма болота.
PS: не в обиду автору этой статьи, но хотелось написать в предыдущей и читателям подобных трудов -– не надо путать сисадмина (тем более без указания профиля) с эникейщиком, которому выпал шанс быстро вырасти по карьере и, надеюсь, профессионально.merlin-vrn
25.07.2017 09:08Вы во многом воспроизвели внутреннюю инструкцию, которую я писал пару лет назад назад для сотрудников. Чтобы ничего не забыли при приёме нового клиента.
Scif_yar
25.07.2017 20:43>>Ну разве сами не догадываетесь, что вместо скомканных советов по тому, с чем именно автор столкнулся, лучше попытаться набросать структуру сущностей
— написано и выложено на самиздате. Включая вами перечисленное. Эта статья — 1-2 страницы из примерно 200.
cyb3rD
25.07.2017 11:03Из комментариев узнал много поучительного. Но никто не упоминает про коллег, которыми нужно управлять. А ведь это основной ресурс. При наличии хорошей документации, регламентов взаимодействия остаётся вопрос управления коллективом. Я с недавнего времени (около 6 мес.) стал руководителем службы АСУ в довольно крупной компании. Пришёл "со стороны". Основные сложности — организация работы службы. Очень интересно ознакомиться с практиками планирования и организации работ. В черновиках идея поста на эту тему. Если кому интересно — пишите. Это поможет мне более активно подготовить познавательную публикацию.
Scif_yar
26.07.2017 22:03думаю про такую статью, но получается лажа. переписываю 6-й раз
bravo-ej
27.07.2017 00:34+2Скорее всего там путного ничего не получится. Я тоже пытался. помимо того, что люди, это ресурс специфический, если только они не на госслужбе любого вида, так ещё и у коллектива есть «история», в которую вы (приходящий руководитель) приходит и всё ломает. Отсюда падает мотивация ещё больше.
С более или менее чёткой философией и советами можно заходить, кмк, только в двух вариантах: с нуля или с тотальной перестройкой и зачисткой.
Всё остальное слишком индивидуально и у меня был бы один совет: пришёл, внедрил систему тикетов и команда сама управляется, получая задачи, записывая документацию в вики, ведя календари регламентов всяких… все кто не вписывается в работу — должны быть либо мотивированы, если они нужны, либо убиты, если не нужны. Из этой эссенции статья не получится)AbnormalHead
01.08.2017 02:59Любая очень большая организация уровня Газпром либо Роснефть алгоритмизируют людей очень даже хорошо. При этом падение мотивации компенсируется либо зп выше средней по региону, либо зп плюс приличный нематериальный бонус (в том числе в виде права с гордостью говорить где работаешь). Связано это с тем что при таком количестве работников без алгоритмизации людского потенциала такие монстры просто развалятся от внутренней энтропии. В результате внизу в таких корпорациях работают неудачники без амбиций, которые не могут сделать шаг к построению своего будущего (фактически безликие винтики большой системы). И при этом они счасливчики, т.к. смогли попасть в эту систему, потому как неудачники без амбиций уходят с таких мест только вперед ногами.
Среднее звено в таких корпорациях более подвижно и может даже достаточно быстро продвигаться по вертикали. Вопрос насколько они при этом компетентны оставим за скобками. Но проблема «эффективных» менеджеров среднего звена присутствует в полный рост. Что рождает много прожектов с красивыми графиками, что сильно повышает «энтропию» системы управления корпорацией. К счастью такие системы достаточно устойчивы и либо перемалывается «эффективный» менеджер (что чаще всего и происходит) и прожект тихо умирает на стадии пилота, либо система переваривает «прожект» и встраивает его последствия в структуру работы (чего чаще всего не происходит). Но всегда результат, как правило, один — нецелевая трата огромаднейшей кучи бабла, которую, вот уж действительно, лучше б просто раздали детским домам и пенсионерам.
Всегда существует опасность, что найдется такой «эффективный» менеджер, но чаще группа менеджеров, действующих каждый по себе в отдельности, но сумма их действий приводит к тому, что система не сможет справиться и корпорация развалится.
imbasoft
Кроме аудита железа и софта надо не забывать про аудит ИБ.
По крайней мере узнать где какие есть криптоключи и когда они заканчиваются. Методику проведения подобного аудита глянуть в статье Аудит СКЗИ и криптоключей