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