Цифровая системная архитектура

8) Управление инцидентами:

Многие организации в современном технологическом мире в какой-то момент сталкиваются с инцидентами.

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

9) Съемные устройства:

Съемные устройства – распространенный способ распространения вредоносного ПО и раскрытия конфиденциальных данных.

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

10) Мониторинг:

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

Архитектор кибербезопасности

Архитектор кибербезопасности вмешивается на уровне архитектуры и инфраструктуры информационной системы компании, чтобы обеспечить безопасность соответствующего оборудования. Именно он определяет политики и стандарты безопасности в компании и должен сообщать о них организации, чтобы гарантировать их соблюдение. Обратите внимание, что у этой профессии есть будущее: по данным АТЭС, в связи с ростом угроз и усложнением архитектур количество вакансий для архитекторов кибербезопасности увеличилось почти на 50% в период с 2016 по 2018 год, большинство из которых связаны с деятельностью в сфере кибербезопасности. ИТ и в более общем плане сфера услуг.

– Многофункциональная роль

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

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

– Внутренняя и внешняя связь

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

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

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

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

Разнообразные рабочие инструменты

Архитектор кибербезопасности может специализироваться, но в целом от него требуется уметь использовать различные инструменты и языки (PHP для веб-приложений, Java, C, C ++ …), владеть несколькими операционными системами (OS, Unix, Linux, Windows).) и быть в курсе последних событий. удобство как в облачных средах и решениях (IaaS, PaaS, API, CASB, O365), так и в мобильности. Он также должен уметь адаптировать свои методы работы в соответствии с тем, что выбрано для управления проектами, будь то, например, совместная работа в гибком режиме или в каскадном режиме.

ЗАКЛЮЧЕНИЕ

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

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

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@

– Микросервисная Архитектура и Кибербезопасность

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

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

Безопасность микросервисов

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

Ключевые проблемы микросервисных архитектур

Проблемы, с которыми сталкиваются микросервисы, заключаются в следующем:

Проблема 1:

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

Проблема 2:

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

Проблема 3:

Следующая проблема, которая является очень важной, – это безопасность каждого отдельного микросервиса. В этой архитектуре все микросервисы взаимодействуют друг с другом одновременно в дополнение к 3-мсторонним приложениям. Поэтому, когда клиент входит в из 3 -й партии приложение, вы должны убедиться, что клиент не получает доступа к данным для микросервисов, таким образом, что он/ она может использовать их.

Сертификация микросервисов

Вышеупомянутые проблемы – не единственные, встречающиеся в микросервисной архитектуре. Можно также столкнуться со многими другими проблемами, связанными с безопасностью, в зависимости от приложения и имеющейся архитектуры. Знания безопасности микросервисов позволяют наилучшими способами уменьшить проблемы.

Рекомендации по повышению безопасности микросервисов :

– Механизм углубленной защиты

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

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

Токены и API-шлюз

Часто при открытии приложения вы видите диалоговое окно с надписью «Примите лицензионное соглашение и разрешение на использование файлов cookie». Что означает это сообщение? Что ж, как только вы примете это, ваши учетные данные пользователя будут сохранены и будет создан сеанс. Теперь, когда вы в следующий раз перейдете на ту же страницу, страница будет загружена из кэш-памяти, а не с самих серверов. До появления этой концепции сеансы хранились централизованно на стороне сервера. Но это было одним из самых больших препятствий в горизонтальном масштабировании приложения.

Токены

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

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

API-шлюзы

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

Согласно статистике, 81,5% предприятий используют приложения на основе микросервисов, и 17,5% из них планируют внедрить микросервисы. Примерно 9 из 10 компаний заявляют, что они удовлетворены внедрением архитектуры микросервисов.

На безопасность микросервисов сильно влияет отличительный несвязанный подход к разработке приложений. Неспособность следовать монолитному подходу вынуждает разработчиков решать новые задачи безопасности в микросервисах.

Далее рассмотрим основные проблемы информационной безопасности, а также, как реализовать безопасность в микросервисах, и о способах обнаружения взломов.

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

Архитектура микросервисов

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

В чем преимущества архитектуры микросервисов? Использование архитектуры микросервисов предусматривает возможность создания масштабируемых и надежных приложений, обеспечивающих следующие преимущества.

– Самодостаточность. Микросервисы – это независимые узлы, выполняющие определенную функциональность.

– Техническое разнообразие. Разработчики могут внедрять различные решения, используя разные технологии.

– Масштабируемость. Функциональность приложения можно быстро расширить за счет разработки и добавления новых сервисов.

– Высокая устойчивость. Сбой одной службы не влияет на все приложение, что помогает обеспечить максимальную безопасность микросервисов.

– Непрерывная доставка. Определенные службы приложения можно обновлять, не отключая все приложение.

– Простая реализация изменений. Функциональность определенных служб может быть обновлена без выпуска основных обновлений приложений.

– Упрощенная адаптация. Новые инженеры-программисты могут быстро подключиться к новому проекту и начать работу над новым сервисом.

Рассмотрим наиболее распространенные варианты использования архитектуры микросервисов Учитывая особенности архитектуры микросервисов, она лучше всего подходит для следующих:

– устаревшие приложения

– крупномасштабные приложения со сложной логикой

– приложения с большим объемом данных

– приложения, обрабатывающие данные в режиме реального времени

– высокоустойчивые приложения

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

– Amazon

– Netflix

– Uber

Отличие архитектуры микросервисов от монолитной архитектуры. Монолитная архитектура – это единое целое, использующее одну базу данных и определенный технологический стек. Приложения microservice, напротив, представляет собой набор взаимосвязанных сервисов, использующих различные технологии.

Остановимся подробнее на основных различиях между монолитной и микросервисной архитектурами.

Monolith vs. Микросервисы

– Масштабируемость Все приложение следует повторно развернуть для выпуска новых изменений или обновлений Новые службы могут быть развернуты без ущерба для всего приложения

– База данных. Приложение использует общую базу данных. Каждый сервис использует эту базу данных

– Команда разработчиков. Разрабатывать, тестировать и поддерживать приложение должна единая команда инженеров-программистов. Для разработки, тестирования и обслуживания сервисов выделяются разрозненные команды.

– Технологии. Разработчики обязаны использовать определенный технологический стек. Каждый сервис может быть разработан с использованием различных технологий.

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

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

Монолитная архитектура против микросервисов

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

Основные проблемы с безопасностью микросервисов в основном вызваны следующим.

– Несвязанная архитектура

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

– Коммуникация с микросервисами

Многие разрозненные сервисы с выделенной функциональностью нуждаются в обмене конфиденциальной информацией.

Ключевые практики обеспечения безопасности микросервисов

Аутентификация и авторизация

Аутентификация относится к проверке личности пользователя путем сверки предоставленных учетных данных для входа с теми, которые хранятся в базе данных.

Авторизация относится к предоставлению зарегистрированным пользователям разрешения на доступ к определенным ресурсам. Он также определяет, какие действия могут выполнять пользователи в зависимости от их ролей.

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

Подход к аутентификации и авторизации Monolith vs microservices

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

Монолитная архитектура Проблемы, связанные с микросервисами

– Вход. Использование единой базы данных. Для выполнения аутентификации и авторизации требуется специальная служба входа в систему.

– Проверка токена идентификации. Одно серверное приложение выдает и проверяет токены ID. Токены ID выдаются и проверяются различными сервисами.

– Доступ к дополнительной информации о пользователе. Все данные хранятся в одной базе данных. Данные и информация о пользователе хранятся в разных базах данных.

Три варианта реализации аутентификации и авторизации в микросервисах

Ниже приведены три варианта реализации шаблонов безопасной аутентификации и авторизации в архитектуре secure microservices.

– Служба аутентификации «все в одном» – cлужба аутентификации проверяет личности пользователей и создает сеанс, выдавая идентификационный токен. Каждая служба проверяет токены и получает дополнительную информацию о пользователе отдельно.

– Хранилище общих сеансов – cлужба аутентификации проверяет личность пользователей и создает сеансы, которые хранятся в выделенном общем хранилище. Службы проверяют идентификатор пользователя и получают дополнительную информацию о пользователе, подключаясь к хранилищу общих сеансов.

– Веб – токены JSON (JWT) – Служба аутентификации проверяет личность пользователя и выдает токен JWT. Токен JWT предоставляется сервисам, которые проверяют его и получают базовую информацию о пользователе.

Плюсы, Минусы и Ключевые факторы

– Универсальная служба аутентификации

– Отличное объединение;

– Основная информация о пользователе всегда актуальна.

– Высокая нагрузка на службу аутентификации;

– Службы ресурсов строго зависят от службы аутентификации.

– Лучше всего подходит для микросервисов, но следует учитывать компромисс в производительности.

– Хранилище общих сеансов

– Простота внедрения;

– Отсутствие строгих зависимостей между аутентификацией и службами ресурсов.

– Худшая инкапсуляция из-за использования общего хранилища сеансов

– Служба аутентификации может стать узким местом / точкой отказа;

– Основная информация о пользователе не является актуальной.

– Высокая производительность при соблюдении некоторых принципов работы микросервисов.

– Веб-токены JSON (JWT)

– Отсутствие узких мест в производительности или точек отказа;

– Продвигает подход к децентрализации;

– Основную информацию о пользователе можно прочитать из JWT.

– Больше данных для передачи по сети;

– Цифровая подпись JWT должна быть подтверждена;

– Сложно реализовать;

– Не обеспечивается «из коробки»;

– Ухудшение поддержки в веб-фреймворках;

– Устранение проблемы JWT.

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

Рассмотрим три варианта аутентификации и авторизации микросервисов, выяснив, как они обеспечивают функциональность безопасности микросервисов.

– Универсальная служба аутентификации. Хранилище общих сеансов Веб-токены JSON (JWT).

– Вход. Уникальный API входа в систему. Уникальный API входа в систему, но сеансы создаются в общем хранилищ. е Служба аутентификации создает JWT, содержащий информацию о пользователе.

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

Доступ к дополнительной информации о пользователе Использование выделенного API службы аутентификации API службы аутентификации микросервисов используется для получения дополнительной информации о пользователе Дополнительная информация может быть сохранена в JWT или извлечена с помощью API службы аутентификации по запросу.

Готовые к использованию решения для идентификации клиентов и управления доступом.

Независимо от того, какой вариант аутентификации и авторизации microservices вы выберете для своего приложения microservice, он должен быть реализован инженерами-программистами.

Готовые к использованию системы идентификации клиентов и управления доступом (CIAM) могут ускорить разработку и решить большинство проблем безопасности, выбрав хорошо протестированное решение. Тремя ведущими платформами CIAM являются:

– AWS Cognito

– FusionAuth

– Auth0

Готовые решения CIAM предоставляют доступ ко многим функциям, обеспечивающим безопасность микросервисов высшего уровня и удобство работы с пользователями. Основными функциями платформы CIAM, входящей в тройку лидеров, являются следующие.

Платформа CIAM. Основные функции

– AWS Cognito. Самостоятельная регистрация, варианты миграции, настраиваемый пользовательский интерфейс, многофакторная аутентификация, защита от взлома учетных данных, оценка рисков безопасности микросервисов, межмашинная аутентификация, хранилище идентификационных данных, доступ к ресурсам AWS.

– FusionAuth. Единый вход, многофакторная аутентификация, биометрическая аутентификация, вход в социальные сети и игры, обнаружение взломанного пароля, авторизация IoT, ограничение скорости.

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

Защищенная связь между микросервисами

Микросервисам необходимо постоянно взаимодействовать друг с другом для отправки и получения данных. Защищенная связь между сервисами является одним из столпов обеспечения безопасности микросервисов. Ниже приведены два рекомендуемых метода обеспечения безопасности взаимодействия микросервисов.

– Использование HTTPS

Протокол безопасной передачи гипертекста (HTTPS) – это безопасный протокол, который позволяет сервисам взаимодействовать друг с другом с помощью сквозного шифрования. Кроме того, рекомендуется настроить каждую службу для автоматической проверки сертификатов служб, необходимых для их подключения.