Как стать автором
Обновить
18
0
Т1 Cloud @T1_Cloud

Облачная платформа

Отправить сообщение

Добрый день. Ссылка указана в тексте: дублирую https://habr.com/ru/article/682762/

IDM позволит увидеть недочеты процедур и поможет при увольнении не упустить «выпавшие» доступы (т.к. она то помнит, что они были).

А если проводить внедрение по правилам, то аудит и пересмотр процессов будут частью внедрения.
Надеюсь, не во время всеобщего карантина?

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

Если же нет, то для таких сотрудников можно использовать VPN. Это избавит от неожиданной головной боли.
Да, это не идеальная защита, но если аутентификация возможна только по паролю, то это намного лучше, чем «ничего».
А в облаках эти проблемы проявляются особенно остро, т.к. их использование обычно начинается с доступа по публичному IP, а вокруг так много соблазнов сделать быстренько и проще.
Да, все скрины с ServiceNow, кроме базы знаний и схемы процесса («Вот такие процессы мы стали писать»)
Спасибо за приятный отзыв. Постараюсь ответить по пунктам.
1. Как говорил ранее, для базы знаний мы используем решение Аtlassian ru.atlassian.com/software/confluence
Про баг: ошибки в ПО(уязвимости) это несколько другой процесс. Для примера можете посмотреть описание в базе знаний топовых вендоров (наш процессы чем-то похожи best practice).
2. Параллельность и связанность знаний и схемы процессов имеется. Мы над этим много работаем.
3. Про шаблоны. У нас все же другой профиль, и в посте я пишу об опыте автоматизации наших процессов. Шаблоны есть, делаем их для себя же по мере необходимости.
4. «Наносится ли на сами изделия какие-то идентификационные коды?»
В самом начале мы думали над нанесением ШК, QR, RFID, но отложили это на перспективу.
5. «Будут ли какие-то сведения из базы знаний раскрыты широкой общественности? Из статьи пример — баг в прошивке.» Пока не планировал. Но, если будет интересный материал, который можно показать общественности, то обязательно напишу.
«Как быть с нехваткой ЗИП при ревизии?»
В перспективе настроим уведомление о необходимости пополнить ЗИП, до этого еще не дошли.

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

" Как быть с теми, кто не отображает установку ЗИП в учётной системе, ссылаясь на срочность решения проблемы? Например нужно было срочно восстановить в короткие сроки сервер, заменив оперативку и не было времени на бюрократические моменты? Ведь, как известно, потом это всё забывается, так ну сделали дело, восстановили сервер, живём дальше".
Это организационный вопрос, по процессу допускается для срочных изменений оформление по факту.

«Предусмотрены ли какие-нибудь дополнительные плюшки при пополнении базы знаний? Как ведётся работа с теми кто базу знаний не пополняет, например, маскируя нежелание под более приоритетными задачами?»
У нас командная работа и все понимают важность документирования. На крайний случай всегда есть руководитель «несогласного» для решения таких вопросов).
окей! обязательно напишу пост на эту тему
момент, неправильно написал. Наоборот, в SN переносим
Базу знаний ведем в confluence. Для инцидентов, изменений, CMDB используем ServiceNow. В перспективе возможно базу знаний тоже перенесем в confluence, чтобы была единая среда для работы.
Даже свои работники не имеют доступа к помещению со стойкой. Это как минимум интересно
Интересность защиты, по нашему мнению, в том, что это целостное единое решение.
Периметры, охрана, разделение доступа, технические системы и т. д. и т. п.
Действительно, ЦОД мы арендуем потому, что это быстро и дешево, особенно учитывая, что под наши задачи нам нужен относительно небольшой ЦОД. Но таких «относительно небольших» нам нужно несколько, причем именно уровня TIER III. Строить их самим просто экономически нецелесообразно.
Когда мы выбираем себе дата-центр для аренды, то ведем очень строгий отбор. И основной критерий тут — безопасность. В посте мы и рассказали о своих критериях по безопасности.
Ну, и, как мы уже сказали выше, скоро мы подключим себе новую площадку и будем использовать два дата-центра.
Между крайностями «дяди в погонах» и «гопники» есть  и еще варианты.
Стоимость оборудования в ЦОД (даже на уровне одной стойки) может достигать нескольких сотен тысяч долларов.
Также данные, которые могут храниться на серверах, размещенных в ЦОД, могут стоить еще дороже.
Вас не смущают  же, например, аналогичные меры по безопасности в банках и денежных хранилищах?
Охрана выбегает не на каждую вибрацию, а только на такую, которую система охраны может ассоциировать с действиями от проникновения человека или по разрушению периметра (забора). Также на место срабатывания датчиков автоматически наводятся камеры системы видеонаблюдения. И уже потом бежит охрана.
В составе круглосуточной смены службы безопасности ЦОД достаточное количество сотрудников, чтобы проверить срабатывание от вибрации гораздо больше одного датчика.
У Ивана была также отличная мысль, что сложность всегда выдавливается в какой-то уровень. Оставить только IP в нашем случае из-за упомянутых в статье услугах ведет к выдавливанию сложности на другие уровни, и в нашем случае в стороны платформ или клиентов. К сожалению, у нас не только наше полностью контролируемое приложение пользуется сетью, присутствует и т.н. «legacy», которое хочет выдавливать сложность в сторону сети и, например, хочет L2 между PoP. Отсюда нам нужен overlay, и вы правильно отметили, что выбора много на рынке. В случае с EVPN (overlay) используется «простая» IP фабрика с ECMP (underlay).
Я не пресейл и не могу отвечать за весь «Техносерв», тем более, я не работал в нем 6 лет назад, но так же отбивался от OTV в то время.
Насчёт «Чем вязать лифы»: а каков анемнез? :) Возможно, и вязать не надо: и 2 коммутатора (последние два слова ведут на ссылку ‪http://blog.ipspace.net/2014/10/all-you-need-are-two-top-of-rack.html‬) хватит для проекта? Решение зависит от множества факторов, мы их упоминали вскользь в статье: можно хоть контроллером и openflow (а-ля Big Switch Fabric) или своей «магией» (а-ля Plexxi). Нет серебряной пули, которая подойдет всем.
Если вопрос в разрезе EVPN, то для «underlay» необходим «IGP». Большинство вендоров сходится, что это *BGP, что считаю логичным, дабы использовать на сети что-то максимально общее — BGP.

Что я думаю по поводу статьи? Думаю, что еще лет 6 назад на ExaBGP делал reduntansy еще без ВМ на bare metal серверах в одной географически (ЦОД-РЦОД) размазанном проекте — можно, работает, удобнее BIRD (IMHO). Кое-кто критикует VXLAN и топит за «MPLS in DC and inter-DC networks». А кто-то делает IPv6 only к хостам и сигнализирует приложениям в битах адресов.
Про DCI — отличный вопрос! Но на него нет единого правильного ответа ни у нас, ни у вендоров. Ответов много и каждый выбирает для себя подходящий. И, к сожалению, тему DCI не раскрыть в одном этом посте. Мы упомянули, что VXLAN можно использовать и без EVPN в IP фабрике на коммутаторах. Но у каждого подхода есть свои плюсы и минусы. Например, поддерживать multicast ради VXLAN, когда есть EVPN c его дополнительными плюшками и оптимизациями, мы не захотели.
Спасибо, вы правы, конечно же. Поправил текст

Информация

В рейтинге
Не участвует
Откуда
Россия
Работает в
Зарегистрирован
Активность