Comments 28
Увы, ничего полезного для enterprise (может быть PAM, но сомнительно), только очередная попытка подсадить на «облачную» иглу от MS. При этом ничего не дается для создания собственного облака, без интеграции с сервисами MS.
Ммм… Для Enterprise — Microsoft Passport. Если реализация получится удачной и будет развиваться, то имхо он станет обязательным элементом в любой корпоративной сети.

Для собственного облака там вагон и телега нововведений в Hyper-V и релиз Azure Stack.

А интеграция с сервисами MS дело добровольное.
Про Passport есть довольно много на Technet. В целом — банально, встроенная двухфакторная аутентификация на основе биометрии/дополнительного устройства/PIN по вкусу.

Плюс сделана в соответствии со спецификациями FIDO Aliance, чтобы обеспечить широкую совместимость.

Что здесь может не понравиться?:)

Здесь может не понравиться только одно: из статьи ничего из перечисленного не очевидно. Тема заголовка, полагаю, абсолютно не раскрыта, и это печалит.
… А если на Технет ходить — ну, тогда и Хабр не нужен )

Эта перевод самой понравившейся мне статьи по нововведениям в Active Directory. Она дает примерное понимание того, что там есть и ключевые слова для поиска деталей.

Если вы видели статью луче, я буду благодарен за ссылку. В следующий раз переведу того автора:)

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


В общем, жаждем далее! Вам в любом случае — спасибо!

Обещаю, следующая статья будет с более глубокой технической частью. Правда, она будет не про Windows Server 2016:)
Посмотрим что будет в итоге.
Но M$ будет выдавливать soho бизнеса в собственные облака.
— Интересно как эта политика ms будет взаимодействовать с законом яровой?
Не выдавливать уж. Просто сотношение цена\функционал будет давить все мелкие компании в облака. Не только в облака MS.

Собственно, это два основных сценария ля облака — компании с динамической нагрузкой (кгда не выгодно постоянно держать достаточно локального железа чтбы комфортно проходить редкие пики) и маленькие компаии (когда хочется отказоустоячивости и богатого функционала, но денег, чтобы развернуть нужные компоненты у себя, нет).

Это тренд от которого, наверное, не уйти.
Облака, облака.
У меня процентов 80 стоимости лицензий — это разный CAL, клиентские ОС и офисы.

В инфраструктуре 80% стоимости — диски и сетевая инфраструктура, пустые серваки стоят по 2-3 тысячи евро всего.

Надеюсь, никто не сомневается в необходимости локального хранения и обработки данных. В типовом бизнесе после этого остаются только базы данных, сервера приложений и AD с прибамбасами. При отсутствии каких-то экстремальных нагрузок на эти компоненты ( что в общем-то — норма для стандартных организаций) их можно и нужно ставить отдельными небольшими виртуалками — благо, на толстых гиперконвергентных платформах для работы большого количества HBA\RAID адаптеров уже давно ставят по 2 камня, и в итоге там они практически не используются как числодробилки.

Оттого все эти облачные тренды — только в головах у маркетологов, а нормальные люди разворачивают инфраструктуру АД в виртуалках с 4-6 гб оперативки и не дурят себе голову.

Арендовать более-менее выгодно только Exchange, так он и в типовой организации должен болтаться где-то около DMZ или с подключенным WAP.
Странно. По тону, вы как будто, со мной спорите. А, по сути, написано тоже самое.

Я, как раз, и говорю, что типовой сценарий для облака это
— Небольшая компания. Вот появилось желание заиметь географически распределённые ресурсы для отказоустойчивости, а денег на аренду места в двух ЦОД и канала между ними нет. Или еще какого экзотичесокго функционала захотелось. Ну неужели покупать всё сопутствующее железо? ПРоще в облаке взять.
— Динамические среды. Приложения с ОЧЕНЬ разной нагрузкой. Веб приложения с наплывами клиентов, системы ИИ (некоторые) и т.д. Какой смысл держать под парами железа для фронтэнда, чтобы справится с рождественским наплывом клиентов, например? Проще держать эту часть в облаке. где она будет гибко масштабироваться по нагрузке.

Понятно, что компании с серьёзной локальной инфраструктурой и более менее стабильными нагрузками оставят все «на земле». Им так и спокойнее и, объективно, комфортнее. Хотя и они интересуются облаками — разместить там тестовые среды (которые опять же хочется быстро разворачивать и быстро убирать по необходимости) или компоненты для удалённых офисов (вместо аренды места у десятка мелких региональных провайдеров (если таких офисов много, они маленькие и раскиданы по всему земному шару).

У вех инструментов есть свое применение. Есть оно и у облаков. А хайп маркетологов, что всё уедет в облака, он должен со временем пройти, да.
Нет. Не оставит. Всё потихоньку переезжает. Вопрос во времени.
>Вот появилось желание заиметь географически распределённые ресурсы для отказоустойчивости, а денег на аренду места в двух ЦОД и канала между ними нет.

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

А вот пул из двух провайдеров где-то дальше москвы и спб пять девяток вам не даст никогда. Потому что всё упрётся аплинки ТТК и Транстелекома. В бизнес-центрах эти ребята не всегда укладываются в 10 т.р. за 5 мегабит, а вне бизнес-центров ставят радиорелейки на оборудовании UBNT в те же деньги.

А в чем заключается "необходимость локального хранения и обработки данных"?
artemlight, наверное, ответит что он имел ввиду, но, как мой вариант ответа:

— Обработка и хранения ваших конфиденциальных данных. То что составляет коммерческую тайну компании имеет смысл держать на доверенном железе. По крайней мере, спокойнее.

— Системы управления технологическим процессом. Зачем выносить в облако системы контролирующие работу и обрабатывающие данные от ваших станков на заводе, например? Будет очень глупо, если с обрывом WAN канала, ваш завод встанет.

— Аналогично с системами управления инженерными компонентами здания. Тоже не ясно зачем выносить в облако то, что собирает данные с локальных датчиков и должно управлять реакцией на эти данные.
Кому как. Для меня например скорость доступа к данным, создание бэкапов и восстановление из них. Да и как-то на Хабре была статья про тупо пропажу данных с AWS, автор еще и доказывал им что он не верблюд, а действительно их косяк. Вот если такое случится, кто ответственность нести будет и компании убытки возмещать?
Да, вспоминается пост хостинг-компании на хабре, когда они сперва получили аварию, а потом не смогли восстановить данные из бэкапов. Закончилось все словами, простите нас, мы не смогли. :)
Генеральному такой ответ будет не по душе.
Что надо бэкапить это понятно, только у меня например данных около 600 Гб, да и канал не самый быстрый, сильно не набэкапишься. Вот вынести в облако часть инфраструктуры как резерв, резервный КД например, как по мне так более лучший сценарий.
Вот здесь вопрос спорный…
Провайдеры предоставляющие облака подобные MS с полной поддержкой Azure единичны. И рядовой сисьадинчег из ООО «Рога и копыта» вскормленный виндой понесет свой бюджет в MS.

Учитывая средний срок жизни ООО 1,5 — 2 года облачный сервис для них выгоднее просто по деньгам, своя инфраструктура обычно окупается 3+ года.
Посмотрим конечно, однако руководство компании очень, очень не любит облака. Почему?
Банально боятся что что то украдут — а они и не знают, отключат — как восстанавливать? Потеряется/потрется — кто виноват? Куда бежать, кому звонить? Да и хваленая отказоустойчевость резко упирается в ковш экскаватора который случайно выкопал оптику/электрический кабель.

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

Хорошо когда Вы крупная и уважаемая компания, а если не очень крупная? Ложится и помирать?

Этот страх он скорее от непонимания того, как это правильно готовить. Можно ведь разносить компоненты ваших систем и уводить в облако стейтлесс системы, которые не хранят конфиденциальных данных. Или использовать облако для быстрого развертывания инфраструктуры обработки гигантских массивов публичных данных и потом сворачивания всего этого с отправкой результата к вам «на землю».

А риски они есть всегда. Когда вы держите сервера в датаруме, ваше здание может сгореть. Когда в чужом ЦОДе, ваш провайдер может перейти дорогу кому не надо и к нему придут маски шоу с отключением всего и вся. У любого варианта есть свои риски и ими нужно управлять понимая их.
Правильная политика на самом деле. С нашим «бешеным принтером» горизонт планирования хорошо если год.
Пару примеров:
Сам оказался в такой ситуации, у нас внезапно вводится новый ГОСТ. Объем и статьи финансирования внезапно стал не сходиться. В гос. органах перенос расходов со статьи на другую, не иллюзорный ахтунг.
Памятный закон Яровой. Была мысль сделать веб-проект исходящий трафик 100-130Мб — пока заморозил, скорее всего реализовывать не будем хранить логи 1год негде.
Банально боятся что что то украдут — а они и не знают, отключат — как восстанавливать?

Облака безопасней инфраструктуры небольшой компании и есть инструменты для бекапа из O365.
Хорошо когда Вы крупная и уважаемая компания, а если не очень крупная?

Урезать осетра и/или думать над снижением рисков другими методами.
ADFS с каждой версией всё лучше, но это тоже околооблачная штука.
Полез гуглить кто умеет SAML 2.0 и оказалось, что в Atlassian Cloud наконец запустили бету, может и в обычный Crowd когда-нибудь завезут его поддержку вместо текущего соплестроя из маркетплейса.
Only those users with full accounts are able to leave comments. Log in, please.