Вопросы Теги

При объединении IntrAnet и HTTPS, действительно ли это полезно?

Это действительно оказывалось поврежденными повторениями в таблицах TFSWarehouse. Мы заплатили за поддержку MS, и они предоставили пользовательский сценарий для исправления проблемы (в основном повторно отображают объекты работы на поврежденном повторении),

0
задан 6 January 2010 в 17:56
6 ответов

Как мы должны знать, существует ли большой риск?

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

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

Существуют способы защитить Сервис HTTP, даже если он не поддерживает само шифрование. Одна возможность состоит в том, чтобы поместить его позади обратного прокси, который говорит HTTPS в передней стороне, и HTTP в спине (должен быть на той же машине, конечно).

Другая возможность состоит в том, чтобы использовать некоторую VPN или даже SSH для туннелирования протокола более высокого уровня (HTTP в этом случае) через безопасный канал.

2
ответ дан 4 December 2019 в 11:23

Можно использовать обратный прокси. Прокси будет иметь сертификат SSL для соединений клиента и соединится с Вашим приложением с не зашифрованным HTTP-соединением.

1
ответ дан 4 December 2019 в 11:23

Вы не сказали, что ОС Вы идете. Если это находится в домене среды домена окон, и изоляция сервера будет шифровать трафик и препятствовать тому не, чтобы доменные машины видели систему. Посмотрите этот акселератор решения для деталей. В среде не для Windows схожая функциональность может быть настроена через IPsec, но это - больше compicated для реализации.

1
ответ дан 4 December 2019 в 11:23

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

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

1
ответ дан 4 December 2019 в 11:23

Это - баланс между

  • что происходит, если кто-то получает кого-то еще учетные данные?
  • что происходит, если данные потеряны?

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

Да, это могло бы быть громоздким, но предложит некоторую защиту от нескольких угроз. Это не 100%-е безопасное решение, но сохранит Вас на Ваших пальцах ног достаточно, чтобы получить подвешивание системы и понять, как это используется. В конце концов, если пользователи требуются придумать длинный пароль с 16 символами, содержащий unicode китайские символы и пунктуация, они могли бы просто сохранить ее на постэтом. Или на кэше браузера. Или на файле PASSWORD.TXT на рабочем столе.

Так, balace потери и усиления и не ЗАБЫВАЮТ сообщать/говорить Вашим супервизорам. Имейте их одобрение в письменной форме, только для предотвращения вины.

1
ответ дан 4 December 2019 в 11:23

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

0
ответ дан 4 December 2019 в 11:23
  • 1
    Основной дефект - то, что веб-приложение никогда не разрабатывалось, чтобы быть безопасным. Основной разработчик никогда не тестировал его на безопасной среде. Кроме того, отсутствие надлежащих сертификатов делает вещи немного сложными. There' s много для фиксации, который занимает время. В основном я должен решить развернуть теперь или через два месяца... –  Wim ten Brink 6 January 2010 в 17:29

Теги

Похожие вопросы