Комментарии

Следование методологии DevSecOps дает разработчикам и бизнесу ряд преимуществ:

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

Сокращение Time-to-market. Обычно продукт проверяется на соответствие ИБ ближе к релизу. Соответственно, при обнаружении любых проблем разработчики вынуждены откатываться к этапу с уязвимостями, устранять их и повторно проверять проект. Это не только сложно и дорого, но и долго, что влияет на сроки релиза продукта. С DevSecOps большинство ошибок удается уловить в момент их появления, что уменьшает время на устранение багов и сокращает Time-to-market.
Улучшение качества продуктов. Концепция DevSecOps подразумевает глубокую проработку всех деталей проекта — сценариев пользовательских действий, нужных функций, вариантов реагирования на уязвимости и не только. Это несколько усложняет проектирование и разработку продукта, но позволяет создать решение, которое больше удовлетворяет запросы пользователей.
Внедрение культуры безопасности. Раньше разработчики были ориентированы на быстрый релиз проектов или оперативное закрытие задач в зоне своей ответственности. Заботы о безопасности, как правило, отдавались на откуп тестировщикам и специалистам по ИБ. С внедрением DevSecOps появляется коллективная и персональная ответственность: любая допущенная ошибка сразу вернется на доработку.
Выстраивание коммуникации и унификация подходов. Тесное взаимодействие разработчиков, тестировщиков, администраторов и безопасников означает унификацию используемых инструментов и методов. Это помогает уйти от «зоопарка технологий» и упрощает онбординг.

Следование методологии DevSecOps дает разработчикам и бизнесу ряд преимуществ:

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

Сокращение Time-to-market. Обычно продукт проверяется на соответствие ИБ ближе к релизу. Соответственно, при обнаружении любых проблем разработчики вынуждены откатываться к этапу с уязвимостями, устранять их и повторно проверять проект. Это не только сложно и дорого, но и долго, что влияет на сроки релиза продукта. С DevSecOps большинство ошибок удается уловить в момент их появления, что уменьшает время на устранение багов и сокращает Time-to-market.
Улучшение качества продуктов. Концепция DevSecOps подразумевает глубокую проработку всех деталей проекта — сценариев пользовательских действий, нужных функций, вариантов реагирования на уязвимости и не только. Это несколько усложняет проектирование и разработку продукта, но позволяет создать решение, которое больше удовлетворяет запросы пользователей.
Внедрение культуры безопасности. Раньше разработчики были ориентированы на быстрый релиз проектов или оперативное закрытие задач в зоне своей ответственности. Заботы о безопасности, как правило, отдавались на откуп тестировщикам и специалистам по ИБ. С внедрением DevSecOps появляется коллективная и персональная ответственность: любая допущенная ошибка сразу вернется на доработку.
Выстраивание коммуникации и унификация подходов. Тесное взаимодействие разработчиков, тестировщиков, администраторов и безопасников означает унификацию используемых инструментов и методов. Это помогает уйти от «зоопарка технологий» и упрощает онбординг.

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

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

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

Еще помните железный век IT, когда вам нужно было покупать собственные серверы и компьютеры? И я уже не помню. Сейчас кажется совершенно безумным, что рост инфраструктуры мог быть ограничен циклом покупки оборудования. Поскольку доставка нового сервера занимала несколько недель, необходимость быстрой установки и настройки на нем операционной системы не стояла так остро. Люди просто вставляли диск в сервер и следовали по пунктам. Через несколько дней он становился доступен для разработчиков. Просто безумие.

С одновременным запуском и повсеместным внедрением AWS EC2 и Ruby on Rails 1.0 в 2006 году многие корпоративные группы столкнулись с проблемами масштабирования, которые ранее возникали только в крупных транснациональных организациях. Облачные вычисления и возможность без усилий запускать новые инстансы виртуальных машин принесли инженерам и предприятиям не только хорошую выгоду, но и дополнительные хлопоты. Теперь им приходилось следить за обслуживаемыми серверами, число которых постоянно росло.

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

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

Infrastructure as Code — ключевой элемент наиболее эффективных инженерных сетапов. То, как сейчас DevOps-инженеры взаимодействуют со своей инфраструктурой — это несомненно большой скачок вперед. Но тем не менее спорные моменты с определением и лучшими практиками IaC до сих пор есть. Эта статья стремится четко описать IaC, его преимущества и важные ограничения.

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

Не могу полностью согласиться с этим. В Symfony магии не больше, чем в других фреймворках. Вообще использование любого фреймворка связано с некоторым уровнем «магии». И это нормально, одна из задач фреймворка — упрощать решение часто повторяющихся задач. Когда вы начинаете работать с фреймворком, вы используете примеры документации, готовые рецепты. При этом некоторые моменты могут быть не столь очевидны, могут быть непонятны, мы часто называем это магией. Вы используете магию фреймворка, и вроде бы всё хорошо. В определённый момент вы чувствуете недостаток стандартных возможностей фреймворка и рецептов, приходит время создать свою «магию». Создавая свою магию, вы разбираетесь в том, как на самом деле работает фреймворк, и в этот самый момент эта часть перестает для вас быть чёрным ящиком, и эта функциональность перестаёт для вас быть магией. Так происходит освоение фреймворка. Не нужно бояться того, что вы сразу не понимаете всех деталей.

Зачастую приходится слышать, что в Symfony очень много магии и не всегда понятно, что откуда получается и самое главное — как работает.

Сложный вопрос. Symfony, если мы говорим о full-stack фреймворке, хорош для относительно крупных проектов. Пожалуй, следует согласиться с тем, что Symfony — не всегда лучший выбор для небольших проектов за несколькими исключениями. Первое — он может быть использован, если требуется решать сравнительно типовые задачи, а выигрыш за счёт быстрого старта и использования стандартных бандлов значителен. Однако в данном случае к выбору следует подходить осознанно, взвесив все преимущества и проблемы, с которыми, возможно, придётся столкнуться. Использование Symfony для мелкого API (можно посмотреть в сторону микро-фреймворков, например, тот же Silex) или простенького сайта можно сравнить с поездкой за продуктами на фуре-длинномере — да, едет, но медленнее и дороже в сравнении с легковыми. Второе исключение — использование Symfony «на вырост» в перспективе расширения проекта и его масштабируемости. В любом случае, инструмент следует выбирать исходя из задач, а не наоборот.

Интересно, а вот Symfony подходит только для крупных проектов?

Symfony слишком сложный. Отчасти это так — у Symfony более высокий порог вхождения по сравнению с другими PHP-фреймворками. Соответственно, и времени на его освоение требуется гораздо больше. Новичкам придется непросто. Здесь и использование инновационных возможностей языка, и применение паттернов проектирования. Нужно быть готовым к тому, что изучением только Symfony дело не ограничится. В придачу следует ознакомиться с технологиями и инструментами, которые идут рука об руку с Symfony и позволят использовать его максимально продуктивно: Twig, SwiftMailer, Monolog, phpUnit, Doctrine, а также наиболее популярные бандлы, например, FOS, Knp, Gedmo и др.

Хакеры пока побеждают, и атаки на приложения по-прежнему представляют угрозу. 88% респондентов сообщили Radware об инцидентах атак в течение года, из них 90% пострадали от утечки данных. Респонденты ежедневно сталкивались с нарушениями прав доступа, перехватом сеансов, подделкой файлов cookie, внедрением кода SQL, атаками типа «отказ в обслуживании», атаками на протокол, межсайтовым скриптингом, подделкой межсайтовых запросов, манипуляциями с API и так далее.

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

Шлюзы API, похоже, не помогают в решении проблемы. Обычно их используют для проверки подлинности (37%), фильтрации IP (30%) и базовой балансировки нагрузки (28%), но очевидно, что они не могут заблокировать все попытки манипуляции API.

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

Из-за быстрого темпа изменений полномочия переходят к другим людям, которые отвечают за гибкую методологию разработки, предоставление приложений и микросервисов, создают среды SLDC и выбирают инструменты. DevOps и DevSecOps начинают оказывать большее влияние при принятии решений, связанных с безопасностью. Именно эту гипотезу компания Radware и хотела проверить.

В дополнение к статье приведу 13 популярных практик для обеспечения безопасности микросервисов

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

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

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

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

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

Из-за большого количества открытых API, портов и компонентов традиционные межсетевые экраны не могут обеспечивать адекватной безопасности для них. Эти проблемы делают развертывание микросервисов более уязвимым для различных киберугроз, таких как «man-in-middle», инъекционные атаки, межсайтовый скриптинг, DDoS.

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

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

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

Среди них можно выделить следующие пункты системы безопасности:

— Защита приложений, микросервисов и пользователей;
— Обеспечение безопасности идентификации и управления доступом;
— Защита данных;
— Повышение безопасности связи между службами;
— Мониторинг микросервисов и систем безопасности.

Популярные практики для обеспечения безопасности микросервисов

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

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

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

1. Безопасность от начала до конца

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

2. Использование концепции «глубокой защиты»

Глубокая защита (DiP) — это метод, при котором человек применяет несколько уровней безопасности в отношении своих сервисов и данных. Эта практика затрудняет проникновение злоумышленников в систему, создавая несколько слоев защиты и обеспечивая тем самым безопасность услуг и данных пользователя.

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

При таком подходе необходимо сначала определить чувствительные зоны сервиса, после чего можно будет применить соответствующие уровни защиты (=создать определенные «стены безопасности» вокруг них).
3. Развертывание системы безопасности на уровне контейнера

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

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

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

Среди типичных инструментов сканирования изображений можно выделить Clair и Anchore,

4. Развертывание многофакторной аутентификации

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

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

5. Использование идентификаторов пользователей и маркеров доступа

При развертывании микросервисов большое количество приложений и служб потребует безопасной авторизации и контроля доступа. Платформы авторизации, такие как OAuth 2.0 и OpenID, позволяют безопасно обрабатывать токены и, следовательно, защищать свои микросервисы. Это дает возможность сторонним приложениям получать доступ к другим службам или данным пользователей.

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

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

6. Создание шлюза API

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

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

Шлюз API координирует все внешние службы и микрослужбы, а также поддерживает многоуровневую защиту системы, соблюдая принципы безопасности.

Среди типичных шлюзов API можно выделить NGINX, Kong, Tyk, Ambassador, AWS API gateway.

7. API-профили, которые созданы на основе зоны развертывания

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

— Ethernet API – интерфейсы для сервисов, открытых миру за пределами центра обработки данных;
— Corporate Zone API – предназначен для внутреннего частного трафика;
— DMZ API – предназначен для обработки трафика, идущего из Интернета;
— Hybrid Zone API – предназначен для развертывания центров обработки данных.

8. Обеспечение связи между службами

Эффективная практика включает в себя аутентификацию и авторизацию запросов при взаимодействии двух микросервисов.

Как правило, существует три основных метода, которые можно использовать для обеспечения безопасности межуслугных коммуникаций. Это Trust the network, JSON Web Token (JWT) и Mutual Transport Layer Security (mTLS или Mutual TLS).

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

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

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

9. Ограничение скорости клиентского трафика

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

Следует настроить свои службы на ограничение работы, если они обнаружат несколько неудачных попыток входа в API или любую другую подозрительную активность.

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

10. Использование менеджеров оркестрации

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

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

Двумя наиболее часто используемыми методами эффективной оркестровки микросервисов являются:

— Кодирование оркестрации как микросервиса;
— Использование шлюза IP.

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

11. Мониторинг всех систем и служб

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

Развертывание непрерывного мониторинга позволяет своевременно обнаруживать и устранять риски безопасности. Для этого существует широкий спектр решений по мониторингу микросервисов, в том числе Prometheus, Statsd, InfluxDB, Logstash.

Мониторинг внутри архитектуры микросервисов

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

— Ведение журналов на уровне приложения. Человек может использовать Splunk, Graphana, ELK stack и другие инструменты, которые создают журналы на уровне приложений, контейнеров, сетей и инфраструктуры;
— Мониторинг метрики использования сети;
— Контроль таких компонентов, как процессор, память, время отклика, ошибки, уведомления, чтобы обнаружить необычные действия, указывающие на существующую или потенциальную атаку;
— Проверка журналов в таких областях, как входящие запросы клиентов, записи базы данных, контейнеры, чтобы выявить несоответствия или необычные действия пользователей.

12. Автоматизация действий по обеспечению безопасности

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

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

13. Защита данных в любое время

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

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

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

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

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

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

Сложная навигация. Множественные переходы и длинные скроллы до целевого действия повышают вероятность, что клиент уйдет.

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

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

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

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

Избыточный дизайн. Используйте два шрифта: один акцидентный для заголовков и второй — легко читаемый, для основного текста. Опирайтесь на правило «60:30:10», где 60% — это основной цвет, 30% — дополнительный, а 10% — акцентный.

Сложная навигация. Множественные переходы и длинные скроллы до целевого действия повышают вероятность, что клиент уйдет.

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

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

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

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

Избыточный дизайн. Используйте два шрифта: один акцидентный для заголовков и второй — легко читаемый, для основного текста. Опирайтесь на правило «60:30:10», где 60% — это основной цвет, 30% — дополнительный, а 10% — акцентный.

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

Концентрация внимания значительно выше в начале списка (эффект первичности) и в конце (эффект новизны). Вот почему правильно расставлять самые важные пункты в начале навигации, второстепенные – в центре. Пункт меню «Контакт» следует разместить в конце TOP навигации в крайнем правом углу.