В случае критических ситуаций и настроений, кстати, очень важно чувствовать момент и вовремя направлять энергию масс. Чтобы 1) обезопаситься и 2) достичь целей.
Почему персональные данные можно отчуждать от владельцев, а какие-то не представляющие ценности аудиовизуальные материалы защищаются государством законодательно по лобби заокеанских стран?
Вопрос риторический. Одна управляющая бань уже сбивала сосули лазерами.
Да, я погорячился :) Автор знает свою аудиторию (или предполагает) и может поставить нужные галочки при публикации. Возможно, рубрикация должна быть более обязательной.
2) почему возникает проблема курица-яйцо? shared fate для управления/данных в этом конкретном случае оправдано: фактически это выбор между консистентностью с потерей узла и потенциальной неконсистентностью. Впрочем, никто не мешает построить отдельно сбоку надежный OOB сегмент.
OpenFlow уже взлетел :) Не дошел до массового рынка, где ему, возможно, появляться рановато в силу специфики оборудования/технологий и инерции сознания.
Не совсем понял вас про новую топологию. Вы имеете в виду возможности гибкого управления потоками (включая произвольный xCMP)?
SDN это оверлей, вы зависите от физической топологии. Я бы очень рамочно сравнил с iBGP в ядре: редко у кого логическая топология повторяет физическую (например, квадрат из 4 маршутизаторов и 6 сессий). Хотите больше физически разнесенных путей — строите линки. Так и с OpenFlow: чем меньше физической централизации, тем 1) больше возможностей для оптимизации логических путей, 2) сложнее этим управлять вручную, 3) осмысленнее внедрение «центрального мозга».
Попробуйте перевести ядро сети на OpenFlow, И напишите книгу-инструкцию. Должно получиться здорово!
1. Небезопасные способы представляются как возможные.
Суть: не имеет смысла рассказывать о решении, которое не предлагает минимальный уровень безопасности.
Аналогия: ехать на машине со спущенными колесами можно, не мыть руки/продукты перед едой можно — в обоих случаях есть примеры ситуаций, когда сказанное будет верным. Это, однако, не относится к нормальной эксплуатации автомобиля и усредненному способу приема пищи.
Вариант №1 использовался когда-то, особенно когда не было необходимости что-то «публиковать». Сервера в нем не защищены от рабочих станций, а станции — от серверов. (В open plan клиенты и сотрудники не находятся в одном помещении, по крайней мере, это не является классическим определением).
Вариант №3 в предложенном виде — иллюзия безопасности. Бэк-энд находится в ситуации из вар.№1. Если вернуться к классической схеме (вариант №2) с двухуровневой фильтрацией, возникает вопрос: а правда ли уровень защиты внутри DMZ и внутри trusted зоны должны принципиально отличаться? Оправдано ли это для не-военных применений (а для военных, в свою очередь, возникнет вопрос: 1) в каком порядке ставить устройства, 2) что делать при компрометации внутреннего уровня, когда внешний еще, вроде бы, не был взломан публично?).
Вариант №4 — первая попытка помочь (кстати, кому? перечислены знания уровня CCNA) делом, однако я сейчас прочитал следующую фразу и удивился:
DMZ разделяется на IP-подсети из расчета отдельная подсеть для каждого узла.
Подсети /30 или /31? v4 или v6? А если серверов много? Ну как «много» — больше, чем /23 делённая на /30 — всего-то 128 шт. А функциональных зон тоже по количеству подсетей или нет? — если нет, зачем подсеть на сервер? (Почему /23 — потому что попробуйте столько найти, если всё, что у вас есть — /29 от провайдера, а сотня серверов — почему бы и нет для небольшого enterprise).
Что касается остальной части списка рекомендаций — именно с этого и стоило начать. Некоторые пункты спорные, чего-то не хватает (я не буду углубляться в подробности — в комментариях есть практически все, что должно было попасть в статью), но именно это было бы пособием по подключению.
Аналогия: вы можете начать объяснять ребенку, приучая к вилке, что раньше люди ели руками. А до этого ели ртом, и не с тарелки. Это никак не поможет вам приучить ребенка к вилке.
Статья же у вас не историческая, а рекомендательная. Если будете начинать историческую, попробуйте составить список RFC, на которые будете ссылаться. Ссылки на RFC сильно дисциплинируют и придают серьезность и ценность даже условно «легкому» чтению.
Вариант №5. Общая схема работы: вы поднимаете туннель в DMZ, а затем отправляете запросы из DMZ вовнутрь защищенного сегмента. Что вы собрались фильтровать на сервере внутри защищенного сегмента? 'drop table' отфильтруете? Я понимаю, что вы делаете, но не понимаю, зачем. Посыл «маршрутизаторов/коммутаторов может не быть / они могут быть не такими, как надо» ложен: нужное оборудование должно быть.
Заключение.
Какой из них лучше, какой хуже — сказать сложно
— нет, не сложно. №4 лучше.
все зависит, в конечном счете, от той информации, которую необходимо защитить, и тех ресурсов, которыми компания располагает для защиты
— верно, но не до конца. Зависит экономическое обоснование. Практически не зависит выбор схемы защиты, поскольку схема защиты у вас в статье ровно одна: поставить за firewall в отдельную зону.
Если ни ресурсов, ни знаний нет, то оптимальным будет первый вариант.
— если ни ресурсов, ни знаний нет, надо найти ресурсы и купить знания. Если нечего продать, чтобы получить знания, возможно, защищать тоже ничего не надо и бизнес тоже открывать не стоит. Но мы же для успешных людей стараемся, верно?
Если же информация очень ценна
— пожалуй, «Если» тут лишнее. Информация очень ценна.
Я, кажется, начинаю понимать проблематику: вы предлагаете выбор между решением с нулевой стоимостью и решением с ненулевой стоимостью. Решение с нулевой стоимостью (в этом конкретном случае) приносит нулевую пользу. Консультация с нулевой пользой репутационно отрицательная. Решение с ненулевой и высокой стоимостью при соответствующем обосновании, даже не будучи востребованным, не может принести отрицательную репутацию.
2. Отсутствует описание и защита автором разделения сети на зоны безопасности.
Суть: объяснить широкому кругу читателей основные понятия современных реалий, не погружаясь в «непрофильный актив» — CAM overflow и проч. Не все понимают, зачем нужны зоны; почему нельзя просто написать много правил адрес-адрес или подсеть-подсеть. Большинство не настраивало сложные экраны а) с нуля б) самостоятельно. Почему бы не подарить радость знания? Казалось бы, просится из статьи для неподготовленного читателя.
3. Суть третьей претензии частично оформлена выше в подробном описании первых двух. Вы прикрываете отсутствие сложного материала и спорные решения утверждением, что нет единственно правильных решений.
Да, их нет, но не в описываемых примерах.
Стали бы вы советовать эти схемы заказчику с 30 офисами и 10 точками присутствия, включающими собственные сервера? А что бы стали? Вот это, вероятно, нашло бы более широкую аудиторию.
Таких заказчиков в мире много тысяч, и ваше решение может быть реализовано у одного из них. Стоит лишь предложить.
//Собственно, получился дайджест предыдущих комментариев к посту.
p.s. пардон, я отвечал на вопрос «какие», а не «как». Но оставлю как есть.
Я несколько раз прочитал про то, как вы уперлись в один гигабит пропускной способности сети. Это всё, конечно, было бы интересно и поучительно, окажись ваш опыт на десять лет раньше.
Можно было бы сказать: «Ага, автор говорит про нищебродство, так в 2008 10Г карточки и правда еще \»не очень\"." Хорошо, тогда 2х1Г, 4х1Г. Но вы же про 2012-2015гг, когда 10Г интерфейс дёшев. Или 2х-4х10Г.
Как у вас получилось не смасштабировать сеть? Или у вас НЕ получилось смасштабировать сеть, и за сухим «достижением предела пропускной способности» стоят десятки бессонных человеконочей?
взрослые парни просто не допускают, чтобы нагрузка на сервера у них превышала 30%
Правильно ли я понимаю, что по мнению автора статьи взрослые парни не допускают выкидывать менее 70% ресурсов серверных систем на ветер? Если это — красочная метафора, не мог бы автор пояснить её смысл?
Потому что когда датацентры борятся за доли процентов эффективности, где-то, возможно, всё совсем не так.
1. Небезопасные способы представляются как возможные,
2. Отсутствует описание и защита автором разделения сети на зоны безопасности (спектр и назначение которых не ограничиваются dmz, trusted и untrusted),
3. Используется спорный вводящий в заблуждение оборот: «В области безопасности нет единственно правильных решений». Я не знаю, что происходит в оторванной от сетевого сегмента безопасности, но в сетевой сфере есть некоторый набор best practices. Любое решение, предлагающее поведение вразрез с best practices, должно быть доказано и проверено.
Но позвольте, из «у нас кучи товаров просто нет» явно следует «за бугром… дешевле». Вслед за отсутствием конкуренции по качеству происходит рост цен на неликвид просто потому, что 1) больше ничего нет и 2) «все равно купят».
Вам этот тезис подтвердит любой мотоциклист России.
Не вводите в заблуждение читателя: не понять вопрос — хуже, чем не знать на него ответа.
Не проверить, правильно ли понят вопрос — гораздо хуже, чем просто не понять вопрос.
Почему-то это иногда становится откровением на собеседованиях.
Давайте начистоту: у кого были эти радужные ожидания? И кто рассчитывал на яблоки на Марсе в скорейшем будущем? Это же немного не честно, ожидать сногсшибательного результата без вложения сногсшибательных в квадрате/кубе/… усилий.
Прогресс в ИТ (могу судить только по инфраструктурной его части) есть, очевиден и серьёзен; именно на порядки, как вы и хотите. Причем за этими порядками в каждом конкретном случае стоят определенные требования бизнеса. Вы можете не заметить этот прогресс, наблюдая за потребительской сферой.
У меня напрашивается нескромное предложение обновить впечатления от прочтения «Суммы технологий» Лема. Я считаю, что в книге отражена одна из самых взвешенных точек зрения на настоящее/будущее из прошлого.
Merit — коммерческая организация, продающая услуги. Участие добровольное.
Вопрос в том, зачем это государству именно в таком виде. Проще собирать данные подключений с провайдеров, что реализуемо автоматически, без ненужных форм/бланков. Можно таблицы MACов передавать.
Принимать закон только чтобы построить граф сродни robtex-овскому… Вспомнилось: «Давно пора, ###на мать, \ Умом Россию понимать».
Есть работающие продукты, использующие управление транспортом посредством openflow. Их можно пощупать и купить, если вы — заказчик с многомиллионным бюджетом. Спектр решений не очень велик, но представлены все области: энтерпрайз, датацентры, WAN.
Поддержка в оборудовании есть (J, A, N) (надо заметить, что в как достаточно дорогом — порядок десятков тысяч, — так и достаточно дешёвом — порядок тысяч), поддержка, как правило, дописывается к существующему hop-by-hop стеку, что 1) не даст возможность развернуть сеть только на openflow, делая сие мероприятие экономически неэффективным, но 2) позволить оценить эксплуатационные качества и выгоды использования в локальных условиях.
Я совершенно не знаком с термином «SDN over Ethernet», но упомянутое туннелирование (было бы хорошо упомянуть WXLAN) имеет больше отношения к intent-based networking.
Давайте определим, о каком значении термина идёт речь:
SDN — не панацея от vendor-lock (впрочем, я плохо понимаю ужас зависимости от производителя),
«SDN» — это такое же размытое понятие, как «VPN»: спросите 5 человек, что это такое/зачем нужно, получите 5 разных ответов. Например, intent-driven networking и использование OpenFlow не подразумевают наличие друг друга.
В случае критических ситуаций и настроений, кстати, очень важно чувствовать момент и вовремя направлять энергию масс. Чтобы 1) обезопаситься и 2) достичь целей.
Вопрос риторический. Одна управляющая бань уже сбивала сосули лазерами.
Не совсем понял вас про новую топологию. Вы имеете в виду возможности гибкого управления потоками (включая произвольный xCMP)?
SDN это оверлей, вы зависите от физической топологии. Я бы очень рамочно сравнил с iBGP в ядре: редко у кого логическая топология повторяет физическую (например, квадрат из 4 маршутизаторов и 6 сессий). Хотите больше физически разнесенных путей — строите линки. Так и с OpenFlow: чем меньше физической централизации, тем 1) больше возможностей для оптимизации логических путей, 2) сложнее этим управлять вручную, 3) осмысленнее внедрение «центрального мозга».
Попробуйте перевести ядро сети на OpenFlow, И напишите книгу-инструкцию. Должно получиться здорово!
Суть: не имеет смысла рассказывать о решении, которое не предлагает минимальный уровень безопасности.
Аналогия: ехать на машине со спущенными колесами можно, не мыть руки/продукты перед едой можно — в обоих случаях есть примеры ситуаций, когда сказанное будет верным. Это, однако, не относится к нормальной эксплуатации автомобиля и усредненному способу приема пищи.
Вариант №1 использовался когда-то, особенно когда не было необходимости что-то «публиковать». Сервера в нем не защищены от рабочих станций, а станции — от серверов. (В open plan клиенты и сотрудники не находятся в одном помещении, по крайней мере, это не является классическим определением).
Вариант №3 в предложенном виде — иллюзия безопасности. Бэк-энд находится в ситуации из вар.№1. Если вернуться к классической схеме (вариант №2) с двухуровневой фильтрацией, возникает вопрос: а правда ли уровень защиты внутри DMZ и внутри trusted зоны должны принципиально отличаться? Оправдано ли это для не-военных применений (а для военных, в свою очередь, возникнет вопрос: 1) в каком порядке ставить устройства, 2) что делать при компрометации внутреннего уровня, когда внешний еще, вроде бы, не был взломан публично?).
Вариант №4 — первая попытка помочь (кстати, кому? перечислены знания уровня CCNA) делом, однако я сейчас прочитал следующую фразу и удивился: Подсети /30 или /31? v4 или v6? А если серверов много? Ну как «много» — больше, чем /23 делённая на /30 — всего-то 128 шт. А функциональных зон тоже по количеству подсетей или нет? — если нет, зачем подсеть на сервер? (Почему /23 — потому что попробуйте столько найти, если всё, что у вас есть — /29 от провайдера, а сотня серверов — почему бы и нет для небольшого enterprise).
Что касается остальной части списка рекомендаций — именно с этого и стоило начать. Некоторые пункты спорные, чего-то не хватает (я не буду углубляться в подробности — в комментариях есть практически все, что должно было попасть в статью), но именно это было бы пособием по подключению.
Аналогия: вы можете начать объяснять ребенку, приучая к вилке, что раньше люди ели руками. А до этого ели ртом, и не с тарелки. Это никак не поможет вам приучить ребенка к вилке.
Статья же у вас не историческая, а рекомендательная. Если будете начинать историческую, попробуйте составить список RFC, на которые будете ссылаться. Ссылки на RFC сильно дисциплинируют и придают серьезность и ценность даже условно «легкому» чтению.
Вариант №5. Общая схема работы: вы поднимаете туннель в DMZ, а затем отправляете запросы из DMZ вовнутрь защищенного сегмента. Что вы собрались фильтровать на сервере внутри защищенного сегмента? 'drop table' отфильтруете? Я понимаю, что вы делаете, но не понимаю, зачем. Посыл «маршрутизаторов/коммутаторов может не быть / они могут быть не такими, как надо» ложен: нужное оборудование должно быть.
Заключение.
— нет, не сложно. №4 лучше.
— верно, но не до конца. Зависит экономическое обоснование. Практически не зависит выбор схемы защиты, поскольку схема защиты у вас в статье ровно одна: поставить за firewall в отдельную зону.
— если ни ресурсов, ни знаний нет, надо найти ресурсы и купить знания. Если нечего продать, чтобы получить знания, возможно, защищать тоже ничего не надо и бизнес тоже открывать не стоит. Но мы же для успешных людей стараемся, верно?
— пожалуй, «Если» тут лишнее. Информация очень ценна.
Я, кажется, начинаю понимать проблематику: вы предлагаете выбор между решением с нулевой стоимостью и решением с ненулевой стоимостью. Решение с нулевой стоимостью (в этом конкретном случае) приносит нулевую пользу. Консультация с нулевой пользой репутационно отрицательная. Решение с ненулевой и высокой стоимостью при соответствующем обосновании, даже не будучи востребованным, не может принести отрицательную репутацию.
2. Отсутствует описание и защита автором разделения сети на зоны безопасности.
Суть: объяснить широкому кругу читателей основные понятия современных реалий, не погружаясь в «непрофильный актив» — CAM overflow и проч. Не все понимают, зачем нужны зоны; почему нельзя просто написать много правил адрес-адрес или подсеть-подсеть. Большинство не настраивало сложные экраны а) с нуля б) самостоятельно. Почему бы не подарить радость знания? Казалось бы, просится из статьи для неподготовленного читателя.
3. Суть третьей претензии частично оформлена выше в подробном описании первых двух. Вы прикрываете отсутствие сложного материала и спорные решения утверждением, что нет единственно правильных решений.
Да, их нет, но не в описываемых примерах.
Стали бы вы советовать эти схемы заказчику с 30 офисами и 10 точками присутствия, включающими собственные сервера? А что бы стали? Вот это, вероятно, нашло бы более широкую аудиторию.
Таких заказчиков в мире много тысяч, и ваше решение может быть реализовано у одного из них. Стоит лишь предложить.
//Собственно, получился дайджест предыдущих комментариев к посту.
p.s. пардон, я отвечал на вопрос «какие», а не «как». Но оставлю как есть.
Я несколько раз прочитал про то, как вы уперлись в один гигабит пропускной способности сети. Это всё, конечно, было бы интересно и поучительно, окажись ваш опыт на десять лет раньше.
Можно было бы сказать: «Ага, автор говорит про нищебродство, так в 2008 10Г карточки и правда еще \»не очень\"." Хорошо, тогда 2х1Г, 4х1Г. Но вы же про 2012-2015гг, когда 10Г интерфейс дёшев. Или 2х-4х10Г.
Как у вас получилось не смасштабировать сеть? Или у вас НЕ получилось смасштабировать сеть, и за сухим «достижением предела пропускной способности» стоят десятки бессонных человеконочей?
Правильно ли я понимаю, что по мнению автора статьи взрослые парни не допускают выкидывать менее 70% ресурсов серверных систем на ветер? Если это — красочная метафора, не мог бы автор пояснить её смысл?
Потому что когда датацентры борятся за доли процентов эффективности, где-то, возможно, всё совсем не так.
Эдриэн Бриджуотер
1. Небезопасные способы представляются как возможные,
2. Отсутствует описание и защита автором разделения сети на зоны безопасности (спектр и назначение которых не ограничиваются dmz, trusted и untrusted),
3. Используется спорный вводящий в заблуждение оборот: «В области безопасности нет единственно правильных решений». Я не знаю, что происходит в оторванной от сетевого сегмента безопасности, но в сетевой сфере есть некоторый набор best practices. Любое решение, предлагающее поведение вразрез с best practices, должно быть доказано и проверено.
Вам этот тезис подтвердит любой мотоциклист России.
Не проверить, правильно ли понят вопрос — гораздо хуже, чем просто не понять вопрос.
Почему-то это иногда становится откровением на собеседованиях.
Прогресс в ИТ (могу судить только по инфраструктурной его части) есть, очевиден и серьёзен; именно на порядки, как вы и хотите. Причем за этими порядками в каждом конкретном случае стоят определенные требования бизнеса. Вы можете не заметить этот прогресс, наблюдая за потребительской сферой.
У меня напрашивается нескромное предложение обновить впечатления от прочтения «Суммы технологий» Лема. Я считаю, что в книге отражена одна из самых взвешенных точек зрения на настоящее/будущее из прошлого.
Вопрос в том, зачем это государству именно в таком виде. Проще собирать данные подключений с провайдеров, что реализуемо автоматически, без ненужных форм/бланков. Можно таблицы MACов передавать.
Принимать закон только чтобы построить граф сродни robtex-овскому… Вспомнилось: «Давно пора, ###на мать, \ Умом Россию понимать».
Поддержка в оборудовании есть (J, A, N) (надо заметить, что в как достаточно дорогом — порядок десятков тысяч, — так и достаточно дешёвом — порядок тысяч), поддержка, как правило, дописывается к существующему hop-by-hop стеку, что 1) не даст возможность развернуть сеть только на openflow, делая сие мероприятие экономически неэффективным, но 2) позволить оценить эксплуатационные качества и выгоды использования в локальных условиях.
Я совершенно не знаком с термином «SDN over Ethernet», но упомянутое туннелирование (было бы хорошо упомянуть WXLAN) имеет больше отношения к intent-based networking.
Давайте определим, о каком значении термина идёт речь:
Хочется добавить:
Сетевым инженерам рекомендую ознакомиться с курсом Ника Фимстера.