Достаточно ли безопасна базовая аутентификация HTTP в CouchDB для репликации в регионах EC2? - PullRequest
6 голосов
/ 13 августа 2011

Я могу оценить, что видеть «базовую аутентификацию» и «достаточно безопасно» в одном предложении очень похоже на чтение «Безопасен ли парашютный спорт без парашюта?», Поэтому я сделаю все возможное, чтобы уточнить, что я получаюat.

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

Чтобы обеспечить безопасную связь между вами и сервером, решение обычно заключается в использовании соединения на основе SSL, когда ваши учетные данные могут быть отправлены в виде простого текста, но канал связи между вами и сервером защищен.

Итак, на мой вопрос ...

В ситуации репликации одного экземпляра CouchDB из экземпляра EC2 в одном регионе (например, us-west) в другой экземпляр CouchDB в другом регионе (например,Сингапур) сетевой трафик будет проходить по пути, который я бы назвал «доверенными» магистральными серверами.

Учитывая, что (при условии, что я не реплицирую высокочувствительные данные) кто-нибудь / все посчитает базовую аутентификацию HTTP для репликации CouchDB достаточно безопасной?

Если нет, уточните, какие сценарии, которые я здесь упускаюсделает эту настройку неприемлемой.Я понимаю, что для конфиденциальных данных это не подходит, я просто хочу лучше понять входы и выходы для не конфиденциальных данных, реплицируемых по относительно надежной сети.

Ответы [ 3 ]

5 голосов
/ 15 августа 2011

Боб прав, лучше ошибиться с осторожностью, но я не согласен. Боб может быть прав в этом случае (подробности см. Ниже), но проблема с его общим подходом заключается в том, что он игнорирует стоимость паранойи. Это оставляет деньги "мирного дивиденда" на столе. Я предпочитаю оценку Брюса Шнайера, что это компромисс.

Краткий ответ

Начните репликацию сейчас! Не беспокойтесь о HTTPS.

Наибольший риск заключается не в перехвате проводов, а в собственной человеческой ошибке, за которой следуют программные ошибки, которые могут уничтожить или повредить ваши данные. Сделайте копию! . Если вы будете регулярно выполнять репликацию, запланируйте переход на HTTPS или что-то подобное (туннель SSH, stunnel, VPN).

Обоснование

Легко ли HTTPS с CouchDB 1.1? Это так просто, как может быть HTTPS, или, другими словами, нет, это не просто.

Вы должны создать пару ключей SSL, приобрести сертификат или запустить собственный центр сертификации - вы, конечно, не настолько глупы, чтобы подписываться самостоятельно! Хешированный пароль пользователя хорошо виден с вашего удаленного дивана! Для защиты от взлома, вы будете осуществлять двунаправленную аутентификацию SSL? Поддерживает ли это CouchDB? Может быть, вам нужен VPN вместо этого? Как насчет безопасности ваших ключевых файлов? Не проверяйте их в Subversion! И не связывайте их в свой EC2 AMI! Это побеждает цель. Вы должны держать их отдельно и безопасно. При развертывании или восстановлении из резервной копии скопируйте их вручную. Кроме того, защитите их паролем, чтобы, если кто-то получит файлы, они не могли украсть (или, что еще хуже, изменить!) Ваши данные. Когда вы запускаете CouchDB или выполняете репликацию, вы должны вручную ввести пароль, чтобы репликация работала.

В двух словах, каждое решение по безопасности имеет свою стоимость.

Похожий вопрос: «Должен ли я запирать свой дом ночью? Это зависит. Ваш профиль говорит, что вы находитесь в Тусконе, поэтому вы знаете, что некоторые районы безопасны, а другие нет. Да, всегда безопаснее всегда запирать все свои двери, но какова стоимость вашего времени и психического здоровья? Аналогия немного ломается, потому что время, потраченное на обеспечение безопасности в худшем случае, намного больше, чем выкручивание болта. блокировки.

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

Вы маленькая рыбка в гигантском океане. Никто не заботится о вас конкретно. Если вы не подвергаетесь конкретному преследованию со стороны правительства или организованной преступности, или кого-то, у кого есть ресурсы и мотивация (эй, это CouchDB - это случается!), То беспокоиться о бугимане неэффективно. Ваши противники бросают широкие сети, чтобы получить наибольшую выгоду. Никто не пытается вас поймать

Я смотрю на это как на интегральное исчисление средней школы: измерение площади под кривой. Время идет вправо (ось X). Рискованное поведение повышается (ось Y). Когда вы делаете что-то рискованное, вы экономите время и силы, но график поднимается вверх. Когда вы делаете что-то безопасным способом, это требует времени и усилий, но график движется вниз. Ваша цель - минимизировать долгосрочную область под кривой, но каждое решение принимается в каждом конкретном случае. Каждый день большинство американцев ездят на автомобилях: самое рискованное поведение в американской жизни. Мы интуитивно понимаем компромисс между риском и выгодой. Активность в интернете одинаковая.

4 голосов
/ 13 августа 2011

Как вы предполагаете, базовая аутентификация без защиты транспортного уровня небезопасна на 100%.Любой пользователь EC2, который может прослушать ваши пакеты, сможет увидеть ваш пароль.Предполагая, что никто не может ошибиться.

В CouchDB 1.1 вы можете включить собственный SSL.В более ранней версии используйте stunnel.Добавление защиты SSL / TLS настолько просто, что нет никаких оправданий этому.

1 голос
/ 15 июня 2012

Я только что нашел это утверждение от Amazon, которое может помочь любому, кто пытается понять риск перехвата пакетов в EC2.

Перехват пакетов другими арендаторами : это невозможнодля виртуального экземпляра, работающего в беспорядочном режиме, для получения или «перехвата» трафика, предназначенного для другого виртуального экземпляра.Хотя клиенты могут переводить свои интерфейсы в беспорядочный режим, гипервизор не будет доставлять им трафик, который им не адресован.Это включает в себя два виртуальных экземпляра, которые принадлежат одному и тому же клиенту, даже если они расположены на одном физическом хосте.Такие атаки, как отравление кэша ARP, не работают в EC2.В то время как Amazon EC2 обеспечивает достаточную защиту от случайного или злонамеренного попытки одного клиента просмотреть данные другого, стандартная практика заключается в шифровании конфиденциального трафика.

http://aws.amazon.com/articles/1697

...