Комментарии 15
покупайте мне смартфон и давайте сим-карту, чтобы я мог пользоваться вашим приложением MFA
Симка разве нужна? А телефоны бывают Б/У, достаточно дешевые
Со слов этого человека - "Конечно нужна. Почему это я должен использовать свой личный номер для получения каких-то корпоративных вещей?". Поверьте, были такие персонажи. Про б\у телефоны - компании сложно будет приобрести б\у телефоны, проще через Партнера закупить партию новых.
У нас при подключении ОТР QR коды для приложения выдавались на внутреннем портале, номер телефона не был никак задействован. Я поэтому и удивился, зачем ему симка понадобилась.
СИМка в данном случае шла бы как бонус к телефону, т.к. только для 2FA смартфона бы хватило, но тогда пользователь скажет: "Раз уж выдали мне телефон, то и корпоративный номер выдайте, чтобы я на связи был и использовал ее только по рабочим моментам, иначе зачем вообще мне этот телефон?". Мы всегда старались идти на встречу нашим сотрудникам, поэтому пришлось бы выдать ему СИМ-карту.
А разве при использовании приложения к телефону не предъявляются какие то доп требования по сторонним приложениям и тепе?
Да, вы 2,5 млн съэкономили за счёт использования оборудования сотрудников. В нормальной конторе предложили бы корп телефоны с разными ограничениями по безопасности но с впн, почтой и месседжером, раз уж удалёнщики есть.
Доп. требований не предъявляется, т.к. само приложение от вендора идет в защищенном исполнении.
В нормальной конторе предложили бы корп телефоны с разными ограничениями по безопасности но с впн, почтой и месседжером, раз уж удалёнщики есть.
Согласен. Но не все компании сразу приходят к такому решению, т.к. оно очень дорогое, да и для пользователей вызовет лишние нервы - если выдать всем корпоративные телефоны и обязать их ими пользоваться, то как быть со своими телефонами? Придется или носить с собой два телефона или как-то ущемлять себя. В общем до такого решения надо духовно дорасти.
Дорасти это да. У нас у отдела который обеспечивал безопасность телефоны всегда были корпоративные. А мне, когда закрыли простой доступ к почте и рекомендовали привязаться к Эксчадж это оказалось неинтересно, потому что в инструкции и соглашении явно указывалось, что я не могу ставить программы которые хочу и если чо админы могут всё обнулить. Я об этом написал админам и начальству и отказался в этом участвовать. Претензий не возникло. Правда с гитхабом пришлось всё равно ставить двухфакторную авторизацию, но требований по ээ.. личному телефону не было никаких. Или их не было в соглашении
В общем-то все бы хорошо, но я увидел в таком решении одно большое «НО». Применение такой архитектуры создает дополнительные угрозы для моей компании, связанные с тем, что мы должны дать прямой доступ сторонней организации к внутренним компонентам своей инфраструктуры, расположенным в защищаемом сетевом контуре. При чем не абы к каким, а к самому Radius серверу, который раздает все разрешения к внутренним сервисам. Тут сразу в голову полезли все возможные сценарии атак, которые можно провести.
А можно поподробнее: зачем открывать стороннему серверу доступ до вашего радиус сервера? Мне казалось ваш радиус серверу обращается к стороннему и в рамках сессии получает ответ.
Не знаю, понятно ли я изобразил, т.к. опустил в этой схеме кучу технических деталей (маршрутизаторы, коммутаторы, СЗИ и прочее), но в общем то суть следующая:
Критические сервисы находятся в изолированной части сети компании. Доступ к ним имеют только внутренние пользователи и внешние пользователи. Доступ внутренних пользователей контролируется кучей разных СЗИ, доступ внешних пользователей осуществляется через VPN и так же контролируется кучей разных СЗИ. В случае, если применять сервисную модель MFA, то мне нужно открыть доступ в изолированную сеть еще одному компоненту, находящемуся в другой сети (сеть поставщика). Для этого прорубается еще один VPN-туннель. Таким образом будет осуществлено взаимодействие компонент изолированной сети и компонент сети поставщика. Как у поставщика разграничена сеть, как у него реализована защита и вообще внутренняя инфра - я не знаю (Красный знак вопроса). Но я точно знаю, что компоненты его сети так или иначе смотрят в интернет (пользователи, сайты и т.п.). Осуществлена ли их изоляция от сервера аутентификации, правильно ли настроены СЗИ и т.п. - это вопрос. Поэтому я вижу следующий риск - нарушитель атакует компоненты сети поставщика (сайт, сервис, да все что угодно, имеющее белые ip), попадает в сеть, добирается до сервера аутентификации, а там уже прямой доступ к моей изолированной сети по прокинутому VPN-туннелю.
VPN у Вас не в изолированную сеть, а только в отдельный интерфейс на Вашем Radius сервере. Светить в этот интерфейс ничем кроме радиуса не надо. Получается, что даже если сервера аутентификации будут скомпрометированы ничего в Вашей сети атакующий кроме радиуса и не увидит.
Все верно. Но радиус сервер то он увидит. Этого достаточно. Если злоумышленник завладел сервером аутентификации у поставщика, то он может сгенерировать ответ моему радиус серверу о том, что пользователь ввел валидные данные для второго фактора аутентификации (где пользователем, подключающимся к моему VPN-серверу будет сам злоумышленник). Таким образом он проникнет в мою изолированную сеть.
Странная схема - ни Мультифактор, ни AzureMFA не требуют открывать порты извне, а сами подключаются к облачному API через NAT. Рассылка QR-кодов по почте и отсутствие проверки при онбординге создаёт больше рисков.
Данная схема как "одна из". Можно осуществить подключение и через NAT, как вы и написали. В любом случае это не повлияет на результат. Если сессия была активирована со стороны Радиус сервера, то злоумышленник имеет возможность сгенерировать нужный ему ответ от Сервера аутентификации (при условии того, что он получил над ним контроль) и передать Радиус серверу.
По поводу рассылки QR на почту - да, риски есть. Эти риски минимизировались временем жизни этого QR, а также возможностью его отсканировать только один раз. Вероятность того, что злоумышленник сможет отсканировать код раньше сотрудника, конечно, была, но данный факт вскрылся бы очень быстро, т.к. легальный пользователь в таком случае не смог бы его отсканировать. И тут злоумышленнику еще нужно было не просто завладеть почтой (а она тоже была защищена разными средствами), а завладеть именно в тот момент, когда на эту почту падал QR и успеть его отсканировать раньше реального сотрудника. В общем, да, вы правы, риски тут действительно были, но я посчитал их незначительными в связи с вышесказанным.
Если уж Банки и различные государственные сервисы, обрабатывающие гораздо более чувствительные данные, не боятся применять эту технологию, то почему должен бояться я?
На Госуслугах можно включить TOTP и некоторые услуги (?) требуют КЭП. А банкам конверсия и снижение издержек намного важнее безопасности клиентов, но сотрудников они авторизуют по сертификату на смарт-карте и нередко только с корпоративного ноутбука.
Чего однозначно делать не стоить - это требовать своё приложение с меняющейся клавиатурой вместо стандартного TOTP, который можно добавить в уже установленный Google Authenticator или Passwords на iOS.
Боль руководителя при внедрении систем безопасности в компании или как я MFA внедрял