Перейти к содержанию

Ковчег для облачного зоопарка


Рекомендуемые сообщения

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

hybrid-cloud-rsa-1-1024x672.jpg

Даже если вы, создавая свою фирму, детально продумали систему безопасности, шансов, что она долго продержится в первозданном виде, немного. Бизнесу свойственно развиваться. Появляются новые проекты, один за другим открываются региональные офисы, требующие централизованной обработки данных, а к разработке ПО подключаются внешние подрядчики. Поглощение — и вы получаете вдобавок к вашей инфраструктуре в частном облаке физическое оборудование. А тут внезапно возникает необходимость запустить новый проект, в работе над которым потребуются аутсорсеры. И вам придется либо организовывать им доступ в свою инфраструктуру (что крайне нежелательно с точки зрения политик безопасности), либо разворачивать среду для общей работы в публичном облачном сервисе.

 

Читать далее >>

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      От KL FC Bot
      Несмотря на некоторые неприятности, произошедшие на рынке криптовалют за последние полгода, в сознании многих людей крипта до сих пор остается символом быстрого обогащения с минимальными усилиями. Поэтому не иссякает и поток мошенников, которые паразитируют на этой теме. Чтобы завлекать жертв в свои сети, эти мошенники продолжают придумывать все новые и новые истории, одна интереснее другой. Сегодня поговорим о свежей схеме, в которой пользователю предлагается забрать средства, якобы намайненные его аккаунтом в некой «автоматической облачной майнинговой платформе».
      Пока вас не было, у вас тут намайнилось
      Все начинается с письма с вложенным PDF-файлом, в котором получателя уведомляют о том, что он вот уже год не входил в когда-то зарегистрированный им аккаунт в некоем сервисе для облачного майнинга биткойнов с незамысловатым названием Bitcoin Cloud Mining. Между тем за это время у него на счету накопилась серьезная сумма — аж 0,7495 биткойна. Но вот беда: поскольку аккаунтом не пользовались почти год, он совсем скоро будет заблокирован, после чего намайненные деньги будут распределены между другими участниками платформы. Времени до блокировки остается немного — правда, не очень понятно, сколько именно: крупным шрифтом в письме указано «2 дня 23:58:38», а мелким — «в течение 24 часов». Но так или иначе, не все потеряно: еще можно успеть войти в аккаунт и забрать средства.
      Во вложенном PDF мошенники обещают получателю крупную выплату, но для этого надо поторопиться — аккаунт вот-вот будет заблокирован
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      Утечки учетных данных остаются одним из самых популярных у злоумышленников способов проникновения в организацию. Только за 9 месяцев 2023 года по данным Kaspersky Digital Footprint Intelligence в даркнете было опубликовано 315 миллионов записей учетных данных, среди которых множество реквизитов доступа к корпоративным ресурсам, в том числе и к ресурсам компаний из списка Fortune 500.  Чтобы эффективнее управлять связанными с этим рисками, минимизировать число уязвимых аккаунтов, быстрее замечать и пресекать несанкционированный доступ, компании внедряют системы управления identity, о которых мы подробно писали ранее. Но эффективный процесс управления identity невозможен, пока большинство корпоративных систем не поддерживают процедуру унифицированной аутентификации. Для внутренних систем компании она обычно завязана на централизованный каталог, например Active Directory, а во внешних SaaS-системах взаимодействие с корпоративным каталогом identity ведется через платформу Single Sign-on (SSO) —либо внешнюю, либо развернутую в инфраструктуре компании, такую как ADFS.
      Для сотрудников это предельно удобно — логинясь во внешние системы, такие как SalesForce или Concur, сотрудник проходит единый для корпоративной сети процесс аутентификации, включая ввод пароля и предъявление второго фактора (кода OTP, USB-токена и так далее, согласно корпоративной политике), ему не нужны никакие дополнительные логины и пароли. Более того, однократно войдя утром в одну из систем, в остальные можно входить автоматически. Помимо удобства этот процесс в теории безопасен, поскольку службы IT и ИБ имеют полный централизованный контроль над учетными записями, парольными политиками, методами МФА и логами.
      Но на практике уровень безопасности внешних систем, поддерживающих SSO, зачастую оказывается не таким уж высоким.
       
      Подводные камни Single Sign-On
      Пока пользователь входит в SaaS-систему, сервер этой системы, клиентское устройство пользователя и платформа SSO проходят несколько этапов взаимодействия, в которых платформа SSO проверяет пользователя и выдает SaaS-системе и клиентскому устройству токены аутентификации, которые подтверждают права пользователя. При этом платформа может снабжать токен целым рядом параметров, напрямую влияющих на безопасность. Они могут включать:
      указание периода действия токена (и сессии), по истечении которого потребуется повторная аутентификация; привязка токена к конкретному браузеру или мобильному устройству; привязка токена к конкретным IP-адресам или IP-диапазонам, что позволяет реализовать в том числе географические ограничения; дополнительные условия окончания сессии, например закрытие браузера или выход пользователя из самой SSO-платформы. Ключевая проблема заключается в том, что некоторые облачные провайдеры неверно интерпретируют или вовсе игнорируют эти ограничения, нарушая таким образом модель безопасности, которую выстроила команда ИБ. Более того, в ряде случаев SaaS-платформы недостаточно контролируют корректность самих токенов, открывая простор для их подделки.
       
      Посмотреть статью полностью
    • DeniTornado
      От DeniTornado
      Доброго всем!
      Переходим на KES с другого продукта. На данный момент активно изучаю справочные материалы. Делаю по шагам, но есть нюансы, вопросы и проблемы. Прошу помочь советом или информацией по данным вопросам на текущий момент
      Дано:
      Облачный Kaspersky Endpoint Security для Бизнеса расширенный. Настроена Облачная консоль для управления. В локальной сети на отдельно взятый сервер установил агент администрирования и объявил его Точкой распространения. Из AD импортировал группы и создал структуру групп как для доменных, так и для ПК не в домене (сервисники, командировочники и т.п.). На несколько ПК уже установил агентов и сам антивирус, подкорректировал немного политики по умолчанию.
      Теперь вопросы и проблемы:
      1) Создаю задачу удаленной установки Агента и кидаю ей в ПК. В свойствах задачи выбираю "Средствами операционной системы с помощью точек распространения" (т.к. агента еще ведь нет). Указываю на какой ПК ставить и указываю, учетные данные для установки - локального админа ПК получателя задачи. Задача отправляется и через минуту ошибка - "Distribution point "SRV-KES-01" has failed to start remote installation. Installation package download from the Administration Server to the shared folder on the device returned an error: Adminis, .\Adminis, Firma\Adminis, <Учетная запись службы Агента администрирования Kaspersky Security Center 14.2> (Отказано в доступе.) No more distribution points have been found.". Если указать в задаче учетные данные доменного админа, то задача отрабатывает нормально. Вот и не понимаю, почему данные локального админа на ПК получателе не нравятся установщику?
       
      2) Некоторые ПК после импорта их из AD все равно имеют состояние "Не видим в сети". Хотя эти ПК включены и с других ПК и серверов в локальной сети нормально пингуются! Что влияет на эту видимость? Какие условия должны быть соблюдены? Это KES через Точку Распространения делает по ICMP или подтягивает как-то по другому?
       
      3) Уже не помню как это у меня получилось.... Столько всего делал уже, но вроде после отработки Мастера первичной настройки. Если зайти в Обнаружение устройств и развертывание-Развертывание и назначение-Инсталляционные пакеты, провалиться например в пакет для Агента под Windows, то внутри есть вкладка "Автономные пакеты" и там есть пакет Агента который я могу скачать и установить в ручную на любом ПК. Но если например, зайти в свойства пакета самого Антивируса KES 12.1 на ту же вкладку, то там пусто. И Как мне получить автономный пакет для самого антивирусного продукта? В Идеале иметь бы такой пакет установки, запустив который вручную на ПК он поставил стразу и агент и сам антивирь за раз. Не нашел как сделать доступным для скачивания пакет для антивируса!
       
      4) Агент администрирования нельзя распространять через GPO в домене AD? В справке вообще не нашел по этому ни строчки! Где MSI? Он есть в природе?
       
      5) Ну и пока странность на MAC Mini моем рабочем. Поставил на него агента через скаченный автономный пакет SH скрипт. Потом через консоль поставил сам антивирус средствами уже самого агента. После первого запуска, я понажимал кнопки Разрешить в интерфейсе антивируса на MAC OS и нажал установить некий сертификат, чтобы Каспер мог HTTPS смотреть. Сертификат вроде как проставился. Но просмотр HTTPS так и не работает

       
      Жмешь Разрешить, вводишь пароль админа MAC OS и все равно такая картина. Не включается HTTPS анализ! Как победить?
      Версия MAC OS Ventura 13.4.1. Версия антивируса, который я поставил через облачную консоль - 11.3.0.320a.
      Просьба кто знает по какому-либо из вопросов помочь. Буду крайне признателен.
      Спасибо!
×
×
  • Создать...