Проектирование управления пользователями для машины

Авиад Мизрахи, InfoWorld |

Новые технологии в анализе технологов

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

Сегодня более 90% интернет-трафика передается между компьютерами. На самом деле машины, использующие ваше SaaS-приложение B2B, также являются пользователями — просто пользователями другого типа. Вот почему сегодня каждое онлайн-приложение и SaaS-приложение должно включать в себя хорошо продуманные методы и политики управления пользователями, специально разработанные для решения различных задач и требований межмашинного взаимодействия (M2M).

Основываясь на многолетнем опыте помощи компаниям B2B SaaS в управлении взаимодействием M2M, я составил краткое руководство с лучшими практиками эффективного, действенного и безопасного межмашинного управления пользователями. Давайте погрузимся.

Контекст может иметь решающее значение для управления пользователями, но он еще более важен для машин, поскольку пользователи машин предоставляют гораздо меньше информации о своем статусе, ситуации и намерениях. Часто пользователи компьютеров получают доступ только к одному сервису или небольшому количеству сервисов, тогда как пользователи-люди имеют доступ к гораздо большему количеству сервисов.

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

Для управления пользователями M2M каждая служба должна знать, как она может взаимодействовать с другими службами и с какими службами ей следует взаимодействовать. Все службы должны знать, как они взаимодействуют с другими службами, а также ключевые службы, на доступ к которым им необходимо предоставить разрешение. Частично это то, что могут обеспечить шлюзы API и сервисные сетки, но ни один из них не имеет ориентированного на пользователя подхода (даже для пользователей M2M).

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

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

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