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

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

Как не надо защищать свои системы в облаке

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 его дополнительными плюшками и оптимизациями, мы не захотели.

Я сетевой архитектор, и меня это беспокоит

Спасибо, вы правы, конечно же. Поправил текст

Кто такой продакт-менеджер на проекте и может ли он получиться из ведущего разработчика?

Так и есть, мы сторонники основательного подхода. Но при этом нисколько не осуждаем MVP подход. Мы часто восхищаемся эджайл-командами, которые умеют быстро «зарелизить» продукт. Но успешных среди таких мало. Чаще всего получается так, что выпущенный минимально жизнеспособный релиз настолько не оправдывает ожиданий пользователей, что последующие усовершенствованные версии их уже мало интересуют. Убытки и подорванная репутация как итог.  

Информация

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