Является ли базовая http-аутентификация в CouchDB достаточно безопасной для репликации по регионам EC2?

Я могу оценить, что видеть "basic auth" и "safe enough" в одном предложении очень похоже на чтение " парашют без парашюта все еще безопасен?- поэтому я сделаю все возможное, чтобы прояснить, к чему я клоню.

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

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

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

в ситуации репликация одного экземпляра CouchDB из экземпляра EC2 в одном регионе (например, США-Запад) в другой экземпляр CouchDB в другом регионе (например, Сингапур) сетевой трафик будет перемещаться по пути того, что я бы назвал "доверенными" магистральными серверами.

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

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

3 ответов


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

короткий ответ:

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

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

обоснование

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

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

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

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

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

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

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


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

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


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

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

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