По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Настроить бэкэнд-службу с нуля сложно. Для облегчения работы можно использовать Firebase, но это не единственное в своем роде решение. В данном материале рассмотрим альтернативные решения бэкэнда для веб-приложений и мобильных приложений.
Что такое бэкэнд?
Бэкэнд - это программное обеспечение, которое обрабатывает данные мобильного или веб-приложения. Он содержит всю логику доступа и управления данными, к которым обычные пользователи не могут получить доступ. Бэкэнд также отвечает за обработку веб-запросов и веб-ответов.
Обычно он известен как часть приложения, которое скрыто от пользователя, и он взаимодействует с фронтэндом (то что пользователь видит), чтобы отобразить запрашиваемые данные.
Для создания бэкэнд-решений можно использовать несколько языков программирования, таких как Python, JavaScript и PHP. В дополнение к этим языкам, вы можете использовать серверные фреймворки, такие как Django, NireJS и Laravel, которые обеспечивают «стандартный» способ построения сложных приложений.
Чтобы создать пользовательское бэкэнд-решение, требуются хорошие навыки работы с некоторыми из упомянутых выше языков программирования, и, что более важно, много времени.
Если вы хотите пропустить этот процесс и сосредоточиться на скорейшем завершении проекта, вы можете использовать готовое к использованию бэкэнд-решение или, если вы предпочитаете модный термин «бэкэнд как услуга» (Baas - Backend-as-a-service).
Наиболее популярным сервисом является Firebase, консолидированный продукт, поддерживаемый Google, но у него есть некоторые недостатки:
Ограниченная миграция данных
Ограниченное хранение данных
Больше нацелен на Android (большие улучшения на iOS в последние месяцы)
Основная служба не является открытой
Для хранения данных приложения и управления ими вы полагаетесь на внешнюю службу
Firebase - отличный продукт, особенно если вы только начинаете, но, чтобы иметь выбор, важно знать некоторые альтернативы.
1. Appwrite
Appwrite - это комплексное бэкэнд-решение практически для каждого веб- или мобильного приложения, о создании которого вы мечтаете. Он является решением с открытым исходным кодом, имеет нулевые зависимости и легко интегрируется (через SDK) с некоторыми наиболее популярными инструментами и языками.
Appwrite - это автономный бэкэнд сервер, который поставляется в виде Docker-образа. Это означает, что ее можно установить в любой ОС, поддерживающей интерфейс командной строки Docker.
Эта кроссплатформенная функциональность позволяет запускать Appwrite на локальном рабочем столе или на любом облачном сервере. Appwrite поставляется со встроенной панелью, которая позволяет управлять приложениями как проектами. Каждый проект может интегрироваться непосредственно с вашим приложением.
Другие интересные особенности Appwrite:
Простота
Отличная документация
Кроссплатформенность
Нулевые зависимости (кроме Docker)
2. Supabase
Supabase - это альтернатива Firebase с открытым исходным кодом, которая выполняет повторяющиеся операции CRUD и позволяет сосредоточиться на вашем продукте.
Помимо возможности самостоятельного хостинга, Как и Appwrite, Supabase можно развернуть локально. Но в отличии от первого, Supabase также предлагается в облачном варианте. Он предоставляет все бэкэнд-услуги, необходимые для создания продукта. Вот основные:
База данных Postgres
Идентификация
Хранение файлов
Автоматически созданные API
Вы можете создать учетную запись в GitHub, выбрать бесплатный план и создать приложение за считанные минуты.
Supabase поставляется с панелью мониторинга, включающая редактор таблиц (аналогично электронной таблице), встроенный редактор SQL и управление пользователями. Имеется обширная официальная документация, которая позволяет быстро начать разработку приложения на этой платформе.
3. Parse Platform
Parse Platform – это полный стек приложений. Его основным продуктом является сервер Parse - бэкэнд сервер с открытым исходным кодом и автономным хостингом, который может быть развернут в любой инфраструктуре, поддерживающей Node.js.
Parse Server использует MongoDB или Postgres в качестве базы данных и позволяет использовать собственную инфраструктуру для развертывания внутреннего сервера. Если вы хотите разработать приложение локально, вы можете сделать это с помощью Node.
ParseplatformIt имеет несколько SDK с открытым исходным кодом, которые позволяют интегрировать почти все существующие веб-приложения или мобильные приложения за пару команд.
Самое интересное в Parse - это широкое сообщество. Они создали множество проектов для расширения функциональности Parse, таких как адаптер MySQL или Live Query for .Net.
4. Cloudboost
Cloudboost - это полнофункциональный JavaScript бэкэнд, включающий все инструменты и инфраструктуру, необходимые для создания современных веб-приложений и мобильных приложений.
При реализации основных функция вроде поиск или аутентификация пользователей, задачу целостности данных это решение берёт на себя. Все находится на одной платформе, поэтому вы экономите много времени и инвестируете в разработку своего приложения.
Главный недостаток: он не является ни открытым, ни бесплатным.
5. Nhost
Хотите использовать современный бэкэнд для создания современных приложений? Если да, Nhost то, что вам нужно. Вдохновленный от Firebase, это готовый к производству бэкэнд, который включает базу данных Postgres, Hasura, GraphQL, встроенную аутентификацию и хранилище.
Как и в случае с каждым из представленных до сих пор бэкэнд-решений, оно предлагает набор SDK для интеграции вашего приложения.
Это решение с открытым исходным кодом, но он предлагает облачную версию, которую вы можете начать использовать бесплатно и выбрать план после того, как вы попробуете его функции. Лучше всего в Nhost то, что у вас есть полный доступ к вашим данным (в отличии от Firebase), и вы можете экспортировать их в любое время.
Nhost только становится, и вы можете наблюдать за их прогрессом и статистикой на их сайте.
Заключение
Backend-as-a-service позволяет делегировать базовае функции приложения и стандартные операции CRUD третьей стороне, чтобы сосредоточиться на создании наилучшего проекта за меньшее время.
Мы продолжаем рассказывать про протокол DHCP (Dynamic Host Configuration Protocol) . Мы уже знаем про принципы работы протокола и про его настройку на оборудовании Cisco, и сегодня речь пойдет о том, как находить и исправлять проблемы (заниматься траблшутингом) при работе с DHCP.
Проблемы с DHCP могут возникать по множеству причин, таких как проблемы программного обеспечения, в операционных системах, драйверов сетевых карт или агентах ретрансляции, но наиболее распространенными являются проблемы с конфигурацией DHCP. Из-за большого числа потенциально проблемных областей требуется систематический подход к устранению неполадок.
Задача 1. Устранение конфликтов IP адресов
Срок действия адреса IPv4 может истекать у клиента, все еще подключенного к сети. Если клиент не возобновляет аренду, то сервер может переназначить этот IP-адрес другому клиенту. Когда клиент перезагружается, то он запрашивает адрес и если DHCP сервер не отвечает быстро, то клиент использует последний IP-адрес. Тогда возникает ситуация, когда два клиента используют один и тот же адрес, создавая конфликт.
Команда show ip dhcp conflict отображает все конфликты адресов, записанные сервером DHCP. Сервер использует команду ping для обнаружения клиентов. Для обнаружения конфликтов клиент использует протокол ARP. Если обнаружен конфликт адресов, адрес удаляется из пула и не назначается, пока администратор не разрешит конфликт.
Выгладит это так:
Router# show ip dhcp conflict
IP address Detection Method Detection time
192.168.1.33 Ping Feb 19 2018 10:33 AM
192.168.1.48 Gratuitous ARP Feb 19 2018 11:29 AM
В столбце IP address указывается конфликтный адрес, в строке Detection Method указывается метод обнаружения (Ping – адрес был обнаружен когда при назначении нового адреса получил положительный ответ на пинг, Gratuitous ARP – конфликт обнаружен в ARP таблице) и Detection time показывает время обнаружения.
Чтобы посмотреть список всех выданных адресов сервером используется команда show ip dhcp binding.
Задача 2. Проверка физического подключения
Сначала нужно проверить, что интерфейс маршрутизатора, действующий как шлюз по умолчанию для клиента, является работоспособным. Для этого используется команда show interface [интерфейс] , и если интерфейс находится в каком либо состоянии кроме как UP, то это означает что порт не передает трафик, включая запросы клиентов DHCP.
Задача 3. Проверка связности, используя статический IP адрес
При поиске проблем DHCP проверить общую работоспособность сети можно задав статический IP адрес у клиента. Если он может достичь сетевых ресурсов со статически настроенным адресом, то основной причиной проблемы является не DHCP.
Задача 4: Проверить конфигурацию порта коммутатора
Если DHCP клиент не может получить IP адрес с сервера, то можно попробовать получить адрес вручную, заставляя клиента отправить DHCP запрос.
Если между клиентом и сервером DHCP есть маршрутизатор и клиент не может получить адрес, то причиной могут быть настройки портов. Эти причины могут включать в себя проблемы, связанные с транками и каналами, STP и RSTP. Конфигурация PortFast и настройка пограничных портов разрешают наиболее распространенные проблемы клиента DHCP, возникающие при первоначальной установке коммутатора.
Задача 5: Проверка работы DHCP в одной и той же подсети или VLAN
Важно различать, правильно ли работает DHCP, когда клиент находится в одной подсети или VLAN, что и DHCP-сервер. Если DHCP работает правильно, когда клиент находится в одной подсети, то проблема может быть ретранслятором DHCP (relay agent). Если проблема сохраняется даже при тестировании в одной подсети, то проблема может быть с сервером DHCP.
Проверка конфигурации DHCP роутера
Когда сервер DHCP находится в отдельной локальной сети от клиента, интерфейс маршрутизатора, обращенный к клиенту, должен быть настроен для ретрансляции запросов DHCP путем настройки helper адреса.
Чтобы проверить конфигурацию маршрутизатора для начала нужно убедиться, что команда ip helper-address настроена на правильном интерфейсе. Она должна присутствовать на входящем интерфейсе локальной сети, содержащей DHCP клиентов, и должна быть направлена на правильный сервер DHCP. Для проверки используется команда show ip interface [интерфейс] . Далее нужно убедиться, что в глобальном режиме не была введена команда no service dhcp . Эта команда отключает все функции сервера DHCP и ретрансляции на маршрутизаторе. Для проверки используется команда show running-config | include no service dhcp. Если команда была введена, то она отобразится в выводе.
Дебаг DHCP
На маршрутизаторах, настроенных как DHCP-сервер, процесс DHCP не выполняется если маршрутизатор не получает запросы от клиента. В качестве задачи по траблшутингу нужно убедиться, что маршрутизатор получает запрос от клиента. Для этого дебага понадобится конфигурация ACL (Access Control List).
Нужно создать расширенный Access List, разрешающий только пакеты с UDP портами назначения 67 или 68. Это типичные порты, используемые клиентами и серверами при отправке сообщений DHCP. Расширенный ACL используется с командой debug ip packet для того чтобы отображать только сообщения DHCP.
Router(config)# access-list 100 permit udp any any eq 67
Router(config)# access-list 100 permit udp any any eq 68
Router(config)# end
Router# debug ip packet 100
IP packet debugging is on for access list 100
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, rcvd 2
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, stop process pak for forus packet
*IP: s-192.168.1.1(local), d-255.255.255.255 (GigabitEthernet1/1), len 328, sending broad/multicast
Результат в примере показывает, что маршрутизатор получает запросы DHCP от клиента. IP-адрес источника равен 0.0.0.0, поскольку клиент еще не имеет адреса, адрес назначения - 255.255.255.255, потому что сообщение об обнаружении DHCP от клиента отправляется в виде широковещательной передачи. Этот вывод показывает только сводку пакета, а не сообщение DHCP. Тем не менее, здесь видно, что маршрутизатор получил широковещательный пакет с исходными и целевыми IP-адресами и портами UDP, которые являются правильными для DHCP.
Другой полезной командой для поиска неполадок DHCP является команда событий debug ip dhcp server. Эта команда сообщает о событиях сервера, таких как назначения адресов и обновления баз.
Router(config)#debug ip dhcp server events
DHCPD: returned 192.168.1.11 to address pool POOL-1
DHCPD: assigned IP address 192.168.1.12 to client 0011:ab12:cd34
DHCPD: checking for expired leases
DHCPD: the lease for address 192.168.1.9 has expired
DHCPD: returned 192.168.1.9 to address pool POOL-1
Параллельно с развитием технологий в сегменте корпоративных сетей повышаются риски компании понести убытки от уязвимостей в безопасности сети. Злоумышленники прибегают к кибер – атакам на сеть предприятия с целью получения и распространения важной коммерческой документации, нанесения урона ИТ – комплексам с целью вывода из строя или нанесении урона по имиджу и репутации компании.
Число зарегистрированных нарушений сетевой безопасность на предприятиях, учебных заведениях и правительственных организациях резко возросло за последние несколько лет. Все чаще советы и даже подробные инструкции по «вторжению» в корпоративную сеть можно найти в свободном доступе в сети интернет, следовательно, специалисты по сетевой безопасности должны анализировать риски и применять определенные методики для предотвращения атак «извне».
Современные угрозы различны: атаки на отказ оборудования DDoS (Distributed Denial of Service), так называемые «черви», «трояны» и программы, предназначенные для похищения важной информации. Эти угрозы могут легко повредить важную информацию, восстановление которой займет много времени.
Рассмотрим подробнее базовые принципы сетевой безопасности, терминологию и решения по безопасности от компании Cisco Systems – Cisco Adaptive Security Appliances (ASA).
Первое, о чем пойдет речь – это «фаервол». «Фаервол» может устанавливаться как на границе сети (защита периметра), так и локально, на рабочих станциях.
Сетевые «фаерволы» обеспечивают безопасность периметра сети. Главная задача такого «фаервола» это запрет или разрешение трафика, который проходит через единую точку входа сети. Правила запрета определяются заранее настроенной конфигурацией оборудования.
Процесс фильтрации трафика включает в себя следующие пункты:
Простая фильтрация пакетов;
Многогранная проверка трафика;
Инспекция пакетов с сохранением состояния;
Трансляция сетевых адресов.
Простая фильтрация пакетов
Цель «простой» фильтрации пакетов заключается в контроле доступа в определенный сегмент сети в зависимости от проходящего трафика. Обычно, инспектирование проходит на четвертом уровне эталонной модели OSI (Open System Interconnection). Например, «фаервол» анализирует Transmission Control Protocol (TCP) или User Datagram Protocol (UDP) пакеты и принимает решение в зависимости от заранее настроенных правил, которые имеют название Access Control Lists (ACLs).
Следующие элементы проходят проверку:
Адрес отправителя;
Адрес получателя;
Порт отправителя;
Порт получателя;
Протокол
Нарушение информационной безопасности влечет прямые финансовые потери компаний
В рамках данного понятия оперирует устройство под названием «прокси-сервер». Прокси-сервер - это устройство, которое выступает посредником от имени клиента защищенной сети. Другими словами, клиенты защищенной сети отправляет запрос на соединение с незащищенной сетью интернет напрямую прокси-серверу [7]. Далее, прокси отправляет запрос в сеть от имени клиента, инициирующего соединение. Большая часть прокси-серверов работает на уровне приложений модели OSI. Фаерволы на базе прокси могут кэшировать (запоминать) информацию, чтобы ускорять работу клиентов. Одно из главных преимуществ прокси-сервера защита от различных WEB атак [10]. Недостаток прокси «фаерволов» - плохая масштабируемость.
Инспекция пакетов с сохранением состояния
Фаерволы по типу Statefull Packet Inspection (SPI) обладает большим функционалом по сравнению с простой фильтрацией пакетов. SPI-фаервол проверяет не только заголовки пакетов, но и информацию на уровне приложений, в рамках поля полезной нагрузки. На фаерволе может быть применено множество правил фильтрации, чтобы разрешать или запрещать трафик в зависимости от содержимого поля полезной нагрузки. SPI отслеживает параметрические данные соединения в течении сессии и записывает их в так называемую «таблицу состояний». В таблице хранится такая информация как время закрытия соединения, время открытия, установления и перезагрузки. Этот механизм предотвращает обширный список атак на корпоративную сеть.
Фаервол может быть сконфигурирован как устройство для разделения некоторых сегментов сети. Такие сегменты называют демилитаризированные зоны, или Demilitarized Zone (DMZ). Подобные зоны обеспечивают безопасность ИТ – комплексам, которые находятся в пределах этих зон, а также, различные уровни безопасности и политики между ними. DMZ могут иметь несколько назначений: например, они могут выступать как сегмент, в котором находится WEB серверная ферма, или как сегмент соединения к «экстранету» партнера по бизнесу.
Выше, изображена сеть, где в DMZ 1 находятся WEB сервера, доступные из сети Интернет, внутренней сети и сети партнера. Cisco ASA, расположенная в центре рисунка, контролирует доступ из сети партнера, ограничивая доступ из DMZ 2 только ресурсам WEB серверов, запрещая доступ к внутренней сети.
В следующих статьях мы расскажем о технологиях трансляции адресов и систем IDS/IPS.