У меня есть веб-сервер, который поддерживает только Intr компании.аnet, а не внешний Intэсеть. Будет около 100 различных пользователей, которые будут подключаться к веб-приложению на этом сервере, и все они будут иметь свои собственные учетные записи. В настоящее время веб-приложение не поддерживает HTTPS из-за некоторых недостатков дизайна, исправление которых требует времени. Итак, у меня есть два варианта: 1) отложить установку приложения до тех пор, пока оно не будет поддерживать HTTPS. 2) Просто установите вещь, потому что нет большого риска, так как она работает только во внутренней сети. Со временем его можно будет исправить и переместить на безопасный сервер.
Данные, которыми управляет веб-приложение, имеют элемент конфиденциальности, поскольку в основном это информация о клиентах. (Но нет данных кредитной карты или банковского счета.) Однако это все еще считается конфиденциальной информацией. Но недостаточно чувствительны, чтобы защищаться любой ценой. И хотя будет один или два пользователя с некоторыми техническими знаниями о компьютерном взломе, большинство пользователей не являются специалистами по ИБ, а просто обычными пользователями. (Все пользователи используют учетную запись обычного пользователя, а не учетную запись администратора. Установка дополнительных программ пользователями становится [почти] невозможной.)
Итак, есть ли большой риск, когда я устанавливаю это приложение для внутреннего пользования через менее безопасное соединение?
Как нам узнать, есть ли большой риск?
Мы не знаем, насколько безопасны ваши пограничные маршрутизаторы, мы не знаем, может ли кто-нибудь войти и подключить свой ноутбук прямо к центральному коммутатору, мы не знаем, есть ли открытая WLAN, которую можно было бы использовать для прослушивания паролей, мы не знаем, есть ли у этих «двух пользователей с некоторыми техническими знаниями» стимул причинить вред - одним словом: мы не знаем что-нибудь чтобы основывать оценку.
Несколько общих советов: вы всегда должны предполагать, что между вашим сервисом и злоумышленником нет ничего. Если используются пароли или какая-либо конфиденциальная информация, все соединения должны быть зашифрованы.
Есть способы защитить HTTP-службу, даже если она сама не поддерживает шифрование. Одна из возможностей - разместить его за обратным прокси-сервером, который передает HTTPS спереди и HTTP сзади (конечно, он должен быть на одной машине).
Другая возможность - использовать какую-то VPN или даже SSH для туннелирования протокола более высокого уровня (в данном случае HTTP) через безопасный канал.
Вы не сказали, на какой ОС вы работаете. Если это находится в среде домена Windows, изоляция сервера зашифрует трафик и не позволит компьютерам, не являющимся доменом, видеть систему. Видеть этот ускоритель решения для подробностей. В среде, отличной от Windows, аналогичную функциональность можно настроить через IPsec, но ее сложнее реализовать.
Вы можете использовать обратный прокси. Прокси-сервер будет иметь сертификат SSL для клиентских подключений и будет подключаться к вашему приложению с помощью незашифрованного HTTP-соединения.
Для внутренней сети, если вы не хотите платить за шаблонный сертификат (или выделенный сертификат для сервера), просто создайте самозаверяющий сертификат. Поскольку это ваша компания, для пользователей не должно быть большой проблемы принять сертификат. И в зависимости от того, как работает ваша сеть (и вашего дружелюбия с администратором), вы можете даже передать ее пользователям, чтобы они не беспокоились.
Если вы имеете дело с какой-либо конфиденциальной информацией, вам следует делать это через HTTPS.
Это баланс между
и с точки зрения денег, и с точки зрения репутации компании, и с точки зрения личной вины, и т. д. Вы можете обойти большинство этих вещей, добавив систему регистрации, которая отслеживает, кто что делает, и, возможно, IP-адрес. Также отслеживайте успешные попытки входа в систему, а не только отклоненные.
Да, это может быть громоздко, но обеспечит некоторую защиту от некоторых угроз. Это не стопроцентно безопасное решение, но оно будет держать вас в напряжении, чтобы разобраться в системе и понять, как она используется. В конце концов, если пользователи должны придумать 16-значный пароль, содержащий китайские символы Unicode и знаки препинания, они могут просто сохранить его на стикере. Или в кеше браузера. Или в файле PASSWORD.TXT на рабочем столе.
Таким образом, сбалансируйте потери и прибыли и НЕ ЗАБУДЬТЕ сообщить / сообщить своим руководителям. Получите их письменное одобрение, чтобы избежать обвинений.
Поскольку ваш сайт предлагает конфиденциальные данные, как вы упомянули, они должны быть зашифрованы. К какому типу относятся недостатки конструкции? Можно ли внедрить правила перенаправления для https, чтобы временно устранить недостатки дизайна?