Модуль ngx_http_geo_module

Пример конфигурации
Директивы
     geo

Модуль ngx_http_geo_module создаёт переменные, значения которых зависят от IP-адреса клиента.

Пример конфигурации
geo $geo {
    default        0;
    127.0.0.1      2;
    192.168.1.0/24 1;
    10.1.0.0/16    1;
    ::1            2;
    2001:0db8::/32 1;
}
Директивы
Синтаксис: geo [$адрес] $переменная { ... }
Умолчание: —
Контекст: http

Описывает для указанной переменной зависимость значения от IP-адреса клиента. По умолчанию адрес берётся из переменной $remote_addr, но его также можно получить из другой переменной (0.7.27), например:

geo $arg_remote_addr $geo {
    ...;
}
Поскольку переменные вычисляются только в момент использования, само по себе наличие даже большого числа объявлений переменных “geo” не влечёт за собой никаких дополнительных расходов на обработку запросов.

Если значение переменной не представляет из себя правильный IP-адрес, то используется адрес “255.255.255.255”.

Адреса задаются либо префиксами в формате CIDR (включая одиночные адреса), либо в виде диапазонов (0.7.23).

IPv6-префиксы поддерживаются начиная с версий 1.3.10 и 1.2.7.

Также поддерживаются следующие специальные параметры:

delete
удаляет описанную сеть (0.7.23).
default
значение переменной, если адрес клиента не соответствует ни одному из заданных адресов. При задании адресов в формате CIDR вместо default можно использовать “0.0.0.0/0” и “::/0”. Если параметр default
не указан, значением по умолчанию будет пустая строка.
include
включает файл с адресами и значениями. Включений может быть несколько.
proxy
задаёт доверенные адреса (0.8.7, 0.7.63), при запросе с которых будет использоваться адрес в переданном поле заголовка запроса “X-Forwarded-For”. В отличие от обычных адресов, доверенные адреса проверяются последовательно.
Доверенные IPv6-адреса поддерживаются начиная с версий 1.3.0 и 1.2.1.
proxy_recursive
включает рекурсивный поиск адреса (1.3.0, 1.2.1). При выключенном рекурсивном поиске вместо исходного адреса клиента, совпадающего с одним из доверенных адресов, будет использоваться последний адрес, переданный в “X-Forwarded-For”. При включённом рекурсивном поиске вместо исходного адреса клиента, совпадающего с одним из доверенных адресов, будет использоваться последний не доверенный адрес, переданный в “X-Forwarded-For”.
ranges
указывает, что адреса задаются в виде диапазонов (0.7.23). Этот параметр должен быть первым. Для ускорения загрузки гео-базы нужно располагать адреса в порядке возрастания.

Пример:

geo $country {
    default        ZZ;
    include        conf/geo.conf;
    delete         127.0.0.0/16;
    proxy          192.168.100.0/24;
    proxy          2001:0db8::/32;
    127.0.0.0/24   US;
    127.0.0.1/32   RU;
    10.1.0.0/16    RU;
    192.168.1.0/24 UK;
}

В файле conf/geo.conf могут быть такие строки:

10.2.0.0/16    RU;
192.168.2.0/24 RU;

В качестве значения выбирается максимальное совпадение, например, для адреса 127.0.0.1 будет выбрано значение “RU”, а не “US”.

Пример описания диапазонов:

geo $country {
    ranges;
    default                   ZZ;
    127.0.0.0-127.0.0.0       US;
    127.
 
 0.0.1-127.0.0.1       RU;
    127.0.0.2-127.0.0.255     US;
    10.1.0.0-10.1.255.255     RU;
    192.168.1.0-192.168.1.255 UK;
}

Начало работы — HTTP сервер Apache Версия 2.4

HTTP сервер Apache Версия 2.4

Available Languages:  en  |  fr  |  ru 

Если вы абсолютный новичок в работе с HTTP-сервером Apache или в запуске веб-сайтов вообще, вы можете не знать с чего начать или какие вопросы задавать. Этот документ познакомит вас с основами.

  • Клиенты, серверы и URL-адреса
  • Имена хостов и DNS
  • Файлы конфигурации и директивы
  • Контент веб-сайта
  • Файлы журналов и устранение неполадок
  • Что дальше?

См. также

  • Comments

Адреса в Интернете записываются с помощью URL — Uniform Resource Locator (унифицированный указатель ресурса), который указывает на используемый протокол (например, http), имя сервера (например, www.apache.org), URL-путь (например, /docs/current/getting-started. html) и, возможно, строку запроса (например, ?arg=value), используемую для передачи серверу дополнительных аргументов.

Клиент (например, веб-браузер) подключается к серверу (например, вашему HTTP-серверу Apache), используя определённый протокол, и отправляет

запрос на ресурс, используя URL-путь.

URL-путь может обозначать множество вещей на сервере. Это может быть файл (как getting-started.html), обработчик (как server-status) или файл какой-то программы (как index.php). Мы рассмотрим это подробней ниже, в разделе Контент веб-сайта.

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

Детали транзакции и условия возникновения ошибки записываются в файлы журналов. Это описывается более подробно ниже, в разделе Файлы журналов и устранение неполадок.

Для того чтобы соединиться с сервером, клиент сначала должен преобразовать имя сервера в IP-адрес — место в Интернете, где находится сервер. Таким образом, чтобы ваш веб-сервер был доступен, необходимо, чтобы имя сервера было в DNS.

Если вы не знаете как это сделать, вам нужно обратиться к сетевому администратору или поставщику услуг Интернета (провайдеру). Они могут сделать это для вас.

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

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

Эта запись будет выглядеть так:

127.0.0.1 www.example.com

Файл hosts, скорее всего, расположен в /etc/hosts или C:\Windows\system32\drivers\etc\hosts.

Вы можете узнать больше о файле hosts и больше о DNS.

HTTP-сервер Apache настроен с помощью простых текстовых файлов. Эти файлы могут располагаться в разных местах, в зависимости от того как вы установили сервер. Общие места расположения файлов можно найти в Вики HTTP-сервера Apache. Если вы установили httpd из исходного кода, то расположение файлов конфигурации по умолчанию следующее: /usr/local/apache2/conf. По умолчанию файл конфигурации называется httpd.conf. Это тоже может варьироваться в сторонних дистрибутивах сервера.

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

Сервер настраивается путём размещения директив конфигурации в этих файлах конфигурации. Директива — это ключевое слово с одним или несколькими аргументами, устанавливающими её значение.

На вопрос: «Где я должен прописать эту директиву?» – обычно отвечают, там где ты хочешь использовать её. Если это глобальная настройка, она должна располагаться в конфигурационном файле вне разделов <Directory>, <Location>, <VirtualHost> или других разделов. Если настройка относится только к конкретному каталогу, значит она должна быть внутри секции <Directory>, которая описывает этот каталог, и так далее. Смотри документ Разделы конфигурации с подробным описанием вышеуказанных разделов.

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

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

Статический контент — это, например, HTML-файлы, файлы изображений, CSS-файлы и другие файлы, которые просто лежат на диске. Директива DocumentRoot указывает где в вашей файловой системе, вы должны разместить эти файлы. Эта директива устанавливается глобально или отдельно для каждого виртуального хоста. Посмотрите в своём файле(ах) конфигурации, чтобы узнать, как именно эта директива используется на вашем сервере.

Обычно, когда запрашивается каталог, без указания имени файла, то будет отдан документ с именем index.html. Например, если для директивы DocumentRoot установлено значение /var/www/html и приходит запрос на адрес http://www. example.com/work/, то файл расположенный по пути /var/www/html/work/index.html будет отдан клиенту.

Динамический контент — это всё что генерируется во время запроса и может изменяться от запроса к запросу. Существует множество способов создания динамического контента. Различные обработчики доступны для генерации содержимого. Могут быть написаны специальные CGI программы для генерации контента на сайте.

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

Для вас, как администратора HTTP-сервера Apache, самые ценные активы — это файлы журналов (лог-файлы), в частности, журнал ошибок. Исправление любой проблемы без журнала ошибок можно сравнить с вождением автомобиля с закрытыми глазами.

Расположение журнала ошибок задаётся директивой ErrorLog, которая может быть установлена глобально или для каждого виртуального хоста. Записи в журнале ошибок расскажут вам, что и когда пошло не так. Зачастую они также смогут подсказать, как что-то исправить. Каждая запись в журнале ошибок содержит код ошибки, по которому вы можете поискать в Интернете более подробное описание того, как решить проблему. Вы также можете настроить журнал ошибок так, чтобы в него записывался идентификатор журнала, который можно сопоставить с записями в журнале доступа — это поможет определить, какой запрос какую ошибку вызвал.

Больше о логирование вы можете узнать в документации о журналах.

Теперь, когда вы знакомы с основами, пора двигаться дальше.

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

  • Загрузки
  • Установка
  • Настройка
  • Старт
  • Часто задаваемые вопросы

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.

Стандарт только для HTTPS. Введение в HTTPS

Ниже приведены некоторые часто задаваемые вопросы и ответы о HTTPS.

Для подробного ознакомления (техническое образование не требуется) ознакомьтесь с презентацией Университета DigitalGov, «Введение в HTTPS» , чтобы узнать, что такое HTTPS и как он защищает веб-службы и пользователей.

  • Что делает HTTPS?
  • Какую информацию защищает HTTPS?
  • Какую информацию предоставляет HTTPS не защитить?
  • Какое отношение HTTPS имеет к HTTP/2?
  • Как переход на HTTPS влияет на поисковую оптимизацию (SEO)?
  • Как сайт HTTPS может продолжать отправлять информацию о реферере на связанные сайты HTTP?
  • Насколько сложно атаковать соединение HTTPS?
  • Почему сегодня доменные имена не шифруются через HTTPS?
  • Почему DNSSEC недостаточно хорош?
  • Как HTTPS защищает от спуфинга DNS?

Что делает HTTPS?

При правильной настройке соединение HTTPS гарантирует три вещи:

  • Конфиденциальность. Соединение посетителя зашифровано, что скрывает URL-адреса, файлы cookie и другие конфиденциальные метаданные.
  • Подлинность. Посетитель общается с «настоящим» веб-сайтом, а не с имитатором или через посредника.
  • Целостность. Данные, передаваемые между посетителем и веб-сайтом, не были подделаны или изменены.

Простое HTTP-соединение можно легко отслеживать, изменять и олицетворять.

Какую информацию защищает HTTPS?

HTTPS шифрует почти всю информацию, передаваемую между клиентом и веб-службой.

Например, незашифрованный запрос HTTP раскрывает не только тело запроса, но и полный URL-адрес, строку запроса и различные заголовки HTTP о клиенте и запросе:

вещи:

То же самое для всех методов HTTP (GET, POST, PUT и т. д.). URL-адрес и параметры строки запроса зашифрованы, как и тела POST.

Какую информацию защищает протокол HTTPS

, а не ?

Хотя HTTPS шифрует весь HTTP-запрос и ответ, разрешение DNS и настройка соединения могут раскрывать другую информацию, например полный домен или поддомен и исходный IP-адрес, как показано выше.

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

Какое отношение HTTPS имеет к HTTP/2?

HTTP/2 (завершено в 2015 г.) — это обратно совместимое обновление HTTP/1.1 (завершено в 1999 г.), оптимизированное для современной сети.

HTTP/2 включает в себя множество функций, которые могут значительно повысить производительность веб-сайта и появились благодаря достижениям Google, продемонстрированным с помощью SPDY в 2009 году.

Хотя HTTP/2 не требует использования внедрил HTTP/2, реализовал только поддержку зашифрованных соединений, и ни один из основных браузеров не работает над поддержкой HTTP/2 через незашифрованные соединения.

Это означает, что на практике основные преимущества HTTP/2 в производительности в первую очередь требуют использования HTTPS.

Для получения дополнительной информации:

  • Часто задаваемые вопросы рабочей группы HTTP/2
  • RFC 7540, окончательная спецификация
  • Состояние реализации HTTP/2, Марк Ноттингем (председатель рабочей группы)

Как переход на HTTPS влияет на поисковую оптимизацию (SEO)?

В целом, переход на HTTPS улучшает SEO и аналитику веб-сайта.

  • По состоянию на август 2014 года Google использует HTTPS в качестве сигнала ранжирования, что может повысить рейтинг в поиске.
  • Переход на HTTPS улучшит аналитику веб-трафика, направляемого с веб-сайтов HTTPS, поскольку информация о реферере не передается с веб-сайтов HTTPS на веб-сайты HTTP.

Чтобы сделать миграцию как можно более плавной и избежать проблем с поисковой оптимизацией:

  • Используйте правильное перенаправление 301 для перенаправления пользователей с http:// на https:// . Не используйте переадресацию 302 , так как это может негативно повлиять на ранжирование в поиске.
  • Используйте элемент канонической ссылки ( ), чтобы сообщить поисковым системам, что «канонический» URL-адрес веб-сайта использует https:// .

Как сайт HTTPS может продолжать отправлять информацию о реферере на связанные сайты HTTP?

По умолчанию, когда пользователь находится на веб-сайте HTTPS и щелкает ссылку на веб-сайт HTTP, браузеры не отправляют Заголовок Referer на веб-сайт HTTP. Это определено в спецификации HTTP 1.1 и предназначено для предотвращения раскрытия URL-адресов HTTPS, которые в противном случае оставались бы защищенными гарантиями HTTPS.

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

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

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

Например, если пользователь находится на https://agency.gov/help/aids.html и щелкает ссылку на https://moreinformation.com , то если origin-when-cross-origin , браузер отправит HTTP-запрос на https://moreinformation.com с заголовком Referer https://agency.gov .

Самый простой способ установить эту политику — включить тег в тело веб-сайта HTTPS:

HTTP-заголовок Referrer-Policy также может использоваться в качестве альтернативного механизма доставки, но он не получил широкой поддержки в веб-браузерах (по состоянию на конец 2016 г.).

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

Насколько сложно атаковать соединение HTTPS?

Атаки на HTTPS-соединения обычно делятся на 3 категории:

  • Компрометация качества HTTPS-соединения посредством криптоанализа или других недостатков протокола.
  • Компрометация клиентского компьютера, например, путем установки вредоносного корневого сертификата в хранилище доверенных сертификатов системы или браузера.
  • Получение «мошеннического» сертификата, которому доверяют основные браузеры, как правило, путем манипулирования или компрометации центра сертификации.

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

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

В первую очередь для поддержки Индикация имени сервера (SNI), расширение TLS, позволяющее обслуживать несколько имен хостов через HTTPS с одного IP-адреса.

Расширение SNI было представлено в 2003 году, чтобы упростить и удешевить развертывание HTTPS, но это означает, что имя хоста отправляется браузерами на серверы «в открытом виде», чтобы получающий IP-адрес знал, какой сертификат предоставить клиент.

Когда сам домен или субдомен раскрывает конфиденциальную информацию (например, «contraception.foo.gov» или «suicide-help.foo.gov»), это может раскрыть эту информацию пассивным перехватчикам.

С точки зрения конфиденциальности сети, сегодня DNS также «сливает» имена хостов в открытом виде по сети (даже при использовании DNSSEC). В сообществе сетевых стандартов продолжаются усилия по шифрованию как имени хоста SNI, так и поиска DNS, но по состоянию на конец 2015 года ничего не было развернуто для поддержки этих целей.

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

Почему DNSSEC недостаточно хорош?

DNSSEC пытается гарантировать, что доменные имена разрешаются для правильных IP-адресов.

Однако разрешение DNS — это лишь один из аспектов безопасного обмена данными в Интернете. DNSSEC не обеспечивает полной защиты домена:

  • После завершения разрешения DNS DNSSEC не обеспечивает конфиденциальность или целостность связи между клиентом и IP-адресом назначения.

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

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

Как HTTPS защищает от спуфинга DNS?

На практике HTTPS может защитить связь с доменом даже при отсутствии поддержки DNSSEC.

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

Чтобы гарантировать, что злоумышленник не сможет использовать спуфинг DNS для перенаправления пользователя на простое соединение http:// , где трафик может быть перехвачен, веб-сайты могут использовать HTTP Strict Transport Security (HSTS), чтобы дать браузерам указание требовать HTTPS-соединение для их владения во все времена.

Это означает, что злоумышленник, который успешно подделывает разрешение DNS, также должен создать действительное соединение HTTPS. Это делает DNS-спуфинг таким же сложным и дорогим, как атака на HTTPS в целом.

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

HTTPS и HSTS совместно защищают домен от спуфинга DNS.

404: Страница не найдена

Качество программного обеспечения

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

Что я могу сделать сейчас?

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

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

Просмотр по категории

Облачные вычисления

  • Знакомство с иерархией ресурсов Azure

    Группы управления Azure, подписки, группы ресурсов и ресурсы не являются взаимоисключающими. Предприятия могут — и часто делают…

  • Начните работу с Amazon CodeGuru с помощью этого руководства

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

  • Упростите управление несколькими облаками с помощью 5 лучших практик

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

Архитектура приложения

  • Когда дизайн REST API превращается из полезного во вредный

    REST может быть непререкаемым стандартом в разработке веб-API, но способствовал ли он чрезмерному доверию? Узнайте, почему другой дизайн …

  • Azure Logic Apps: чем они отличаются от AWS Step Functions

    Разработчики могут использовать Microsoft Azure Logic Apps для создания, развертывания и подключения масштабируемых облачных рабочих процессов. Узнайте, как он измеряет …

  • 5 способов справиться с проблемами монолитных архитектур

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

ITОперации

  • Шаг за шагом создайте сценарий мониторинга производительности PowerShell.

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

  • Пошаговое руководство. Начало работы с Weave для Kubernetes

    Хотите упростить управление сетью для кластеров Kubernetes? Узнайте, когда и как использовать плагины CNI, а затем пройдитесь по …

  • План кибербезопасности Белого дома противоречит реальности SecOps

    Стратегия кибербезопасности Белого дома ставит перед собой высокие цели. Но недавние маркетинговые исследования показывают, что значительное количество предприятий …

TheServerSide.com

  • Почему WebAssembly? 11 основных преимуществ Wasm

    Задержка и задержка мешают веб-приложениям, которые запускают JavaScript в браузере. Вот 11 причин, по которым WebAssembly имеет …

  • Почему Java в 2023 году?

    Было ли когда-нибудь лучшее время для Java-программиста? Платформа Java — от новых выпусков Spring до активных JUG — …

  • Как разработчики могут избежать мошенничества с удаленной работой

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

ПоискAWS

  • AWS Control Tower стремится упростить управление несколькими учетными записями

    Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь.

    No related posts.