Представьте ситуацию: вы спокойно спите и видите свой третий сон, как вдруг раздается телефонный звонок — недовольный клиент жалуется, что вся система недоступна. Согласитесь, подобные события — дискомфорт для жизни AEM-разработчика, всей команды и провайдера решения. Ничего не попишешь, ранний подъем и поиск решения впереди. Чтобы в вашей профессиональной жизни не встречалось таких нерадостных моментов, расскажу о типичных проблемах безопасности и как от них лучше застраховаться.


 
 Придерживаться буду такого плана:  Мир проектов на AEM станет еще лучше, если каждый разработчик, будет владеть общим пониманием того, как можно в целом защитить платформу от утечки данных. Согласно схеме ниже, у нас есть автор, несколько паблишей и два или более диспатчеров (так называемые балансеры). По сути, этим трём уровням и стоит в первую очередь уделить внимание в плане защиты данных. Это классические правила работы, которые общеприняты в AEM-сообществе по всему миру. 1. Использовать HTTPS. AEM быстро развивается, предоставляет гибкие возможности для создания автора на другом более защищенном протоколе. Достаточно сгенерировать ключ “SSL Wizard”, создать путь к нему и, таким образом, использовать более защищенный протокол. В рекомендациях от Adobe — этот шаг как раз и является первоочередным в безопасности. 2. Установка пакетов с последними обновлениями. Стандартный процесс разработчика сводится к тому, что при работе над компонентами и сервисами решения приходится искать в Google. Цель этого шага — регулярно следить за Service pack & Hot Fixes. Тогда уходят очень многие проблемы, в том числе и связанные с сохранностью данных. Хотя это и не панацея, но важный момент — держать систему в актуальном состоянии. 3. Создание аккуратных страниц с сообщениями об ошибках. Если изначально сделать страницу с кратким описанием ошибки, клиент сразу увидит, что не работает, в то время как девелопер уже будет в процессе решения проблемы. Логично, что эта информация не пройдет мимо вас, но вы избежите паники от клиента и тестировщиков, путаницы в задачах. 4. Отказаться от установки пароля и логина на «admin-admin». Как бы не было смешно, но проблема с некачественными логином и паролем достаточно распространена даже в AEM. По итогу в погоне за скоростью или другими соображениями мы получаем максимально уязвимую систему. Как только вы обнаружили, что установлены примитивные данные для входа, постарайтесь убедить команду/начальство и поменять их на более надежные как можно скорее. Во-первых, пользуйтесь vpn. Использование Virtual Protected Network — это работа защищенной приватной сети для установки защищенного соединения между вами и сервером. Это простой и важный инструмент: так ваш трафик будет зашифрован, вычислить, откуда отправляете свои данные невозможно. Получается, с vPn никто не сможет получить доступ к вашему инстанс.  Такой подход подойдет удаленным разработчикам и всем тем, чья работа ведется из разных локаций с нестабильным интернет-соединением. Во-вторых, ваш “автор” всегда должен быть закрыт, в том числе из Google. Так можно подобрать пароль и взломать систему: по неосторожности автор может быть проиндексирован. Чтобы проверить вашу уязвимость в поисковике, наберите в его строке свой домен и автора и путь к crx. Да, можно обращаться в Yandex или Google с просьбой удалить такую строку в выдаче. Но, пока вопрос решается, система уже будет общедоступная.  В-третьих, не недооценивайте привилегии пользователя “admin”, у которого чаще всего есть возможность совершать любые доступные операции.  Это особенно критично на момент, когда сотрудник прощается с компанией. Ведь у большинства бизнесов доступ к инстанс не персональный, а через один администраторский аккаунт. Логичнее сделать наоборот и быть в курсе конкретных изменений в системе от конкретного автора. В версии AEM 6.1 появился новый подход, когда можно задать конкретные права для бандла или сервиса пользователя. Но все же лучше сделать именной профиль: и сотруднику приятно, и бизнесу проще отслеживать, у кого какие уровни доступа в систему. Такой подход актуален для уровней автора и паблиша. Как правило, только спустя продолжительное время на проекте замечают, что не сделали проверку анонимного пользователя. И в то время, как у обычного пользователя могут быть ограничения по операциям, у анонимного — часто случается, намного больше прав на выполнение операций. Фильтр Apache Sling Referrer — удобный и действенный механизм сделать безопасным ваше приложение. Например, отправляете метрики в AEM, вы видите в Inbox информацию об отправке данных. Если вы превышаете дефолтное значение, сторонняя система может отправить этот запрос. Это значит, что кто угодно не сможет направить запрос. Вы заносите домен в конфигурацию, она в момент запроса сверяет его с изначально занесенными данными и, если все совпадает, интеграция происходит. С фильтром получится провести более гибкую настройку: указать можно запрос, метод, хост. Также там есть пустое значение или звездочка для более детальных запросов. Девелоперы сталкиваются с диспатчем в 10% случаев. Итак, это основной конфигурационный файл, где мы задаем тип урла (запрещающий / разрешающий). Обычно разработчики делают маленький таск, создают правило и забыли, что оно добавит уязвимость. Чтобы никто не попытался атаковать ваш инстанс, нужно проверить url с селекторами на момент доступности. Через конфигурационный файл можно указать обработку заголовков. Потому что чем более точно укажете заг, метод и т.д, такая детальная настройка точно ничего не поломает. Это элементарные примеры. Что если таких правил сотни и навигация по ним сложнее? Самый простой способ — включить логирование. В зависимости от версии Apache, может чуть меняться механизм работы. Но вам система сразу подсветит, по какому url какое конкретно правило у вас отрабатывает и что все еще необходимо подправить. Также в правилах можно указывать домены: это — отсылка к интерграции. 
Раз диспатчер используется для кеширования, запросы выполняются в разы быстрее: не нужно никуда ходить и проверять, и можно сразу отдавать клиенту. Плюс такой способ сильно повышает безопасность вашего приложения. Cross Site Request Forgery — подделка запроса. Общий принцип работы CSRF: предположим, на сайте банка вы используете свой аккаунт. После авторизации у вас есть стандартная сессия с cookies в браузере, получаете письмо и переходите по ссылке на подозрительный сайт. На нем злоумышленник встроил форму, при заполнении которой ваши данные отправляются на сайт банка. Дело — в HTTP протоколе. Злоумышленнику не нужно много данных: достаточного этого запроса. Сервер банка увидит: пришел запрос, есть cookies и сессия, все впорядке. Так работают типичные атаки. Что может дать AEM, чтобы предотвратить подделки запросов
Классический пример защиты — генерация “секрета” в строку. Когда генерируется форма, этот секретный токен добавляется из скрытого поля. Если зайти на сайт злоумышленника, система обнаружит отсутствие токена или его невалидность и откажет в отправке данных. Иногда делают защиту от самих пользователей. Теперь у вас обычный ajack, в которое скрытое поле не добавить. На стадии авторизации сервер возвращает вам cookie с название с SCRF, перекладываете ее в заголовок, отправляете на сервер. Так вы подписали запрос. Бывают кейсы, когда приложение пишут на React и есть сложный момент с интеграцией. В AEM учли эту ситуацию: достаточно сходить на inpoint и подписать это на проверку. Подходит, когда используете нестандартные компоненты и библиотеки. Что еще можно сделать для защиты системы:
  Целью является — исчерпать физические возможности сервера. Делаются миллионы запросов по какому-то хосту. Когда их становиться бесконечно много, система и начинает физически не справляться. Как правило, атакуют мощно из нескольких источников, используют VPN. На 100% от такого не застрахован никто; но давайте не будем им помогать. В каких случаях система уязвима:

  Чтобы ваша работа на AEM стала более безопасной, фокусируйтесь на возможностях конкретных пользователей. Не забудьте пройти по Adobe Security Checklist, и пускай с вашим проектом на AEM все будет стабильно хорошо. Маркетинг, Big Data, CMS