Цифровая системная архитектура
- -
- 100%
- +
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) – это безопасный протокол, который позволяет сервисам взаимодействовать друг с другом с помощью сквозного шифрования. Кроме того, рекомендуется настроить каждую службу для автоматической проверки сертификатов служб, необходимых для их подключения.