Size: a a a

DevSecOps - русскоговорящее сообщество

2019 May 11

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
Konstantin Sverdlov
>>> google -> 2FA SSH with Google
I already use an authenticator app, why should I use Krypton?
The simple answer is that you'll be able to login faster. No more typing 6-digit codes or even reaching for your phone. Krypton securely takes care of providing your second factor.

Beyond convenience, you'll be immune to phishing. You don't have to worry that you're typing the code into the right website -- Krypton takes care of this for you under the hood. Krypton implements FIDO U2F to prevent phishing.

6-значные пины - это больно.
это не является проблемой, пин живет всего около минуты по дефолту, вернее в окне 30 сек живут два пина, количество попыток ввода ограничено - если специально никто нигде не ошибся перебор невозможен - в чем проблема то?
источник

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
Konstantin Sverdlov
>>> gravitational.com/teleport

Это же не про 2FA. В community версии нет SSO полноценного.
сам 2fa в отрыве от реально решаемой задачи никому нафиг не нужен, если решается вопрос доступа к серверам все равно нужен бастион - teleport на рынке самое доступное решение после самописных, да и даже за деньги(от 15к$/год) он остается одним из самых доступных - все остальное имеющее сопоставимые фичи стоит дороже.
Если к сервису прикручивать то опять же - это гемор для пользователя тк нужно еще одно приложение, в то время когда уже практически стандарт нарисовался.
Что бы эта штука взлетела надо для начала сделать обратную совместимость с тем что сделал гугл и предлагать опционально "расширенную безопасноть",  а параллельно еще и доказать что в этом резон есть, написать либы для быстрой интеграции в php5\7, go, nodejs и может даже ror.
Сейчас это выглядит как стартапчик с модным стеком - rust+go(зачем вообще эта смесь адская) без идеи как это продать. У нас 1,6М зареганных юзеров, все с двухфакторкой(без нее не зарегаешься), за 5 лет ни одного зарегестированного кейса когда злоумышленник бы обошел ее. Так какой профит тратить силы на внедрение?
источник

KS

Konstantin Sverdlov in DevSecOps - русскоговорящее сообщество
Gleb Mekhrenin
это не является проблемой, пин живет всего около минуты по дефолту, вернее в окне 30 сек живут два пина, количество попыток ввода ограничено - если специально никто нигде не ошибся перебор невозможен - в чем проблема то?
Дело не в переборе, дело в фишинге. Есть много готовых инструментов, позволяющих делать mitm, перехватывать коды двухфакторки. Время жизни в 30 секунд тут не важно — жертва вводит otp на фишинговый ресурс, видит непонятную ошибку или просто перенаправляется уже на окно аутентификации реального сайта, а злоумышленник уже увел сессию.
источник

KS

Konstantin Sverdlov in DevSecOps - русскоговорящее сообщество
Второе, более важное для меня отличие - пуши. Мои пользователи избалованы и не готовы вводить 6 цифр каждый раз. У krypt.co - пуши.
источник

KS

Konstantin Sverdlov in DevSecOps - русскоговорящее сообщество
Про бастион (джамп сервер) - все тоже не так однозначно. В кровавом энерпрайзе в интранете бастион ослабляет безопасность сетевых доступов. На примере: есть сегментированная сеть (подсети разработчиков, админов, много подсетей для разных типов серверов и т.п.). Если используется прямой доступ по ssh без бастиона, то можно пилить точечные сетевые доступы (от сети разработчиков - к дев серверам, от сети админов - к прод серверам и подобное). А если используется бастион, то сетевые доступы предоставляются всем до него и от него на все сервера. Пилить в каждую подсеть по отдельному бастиону - такое себе.
источник

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
Konstantin Sverdlov
Про бастион (джамп сервер) - все тоже не так однозначно. В кровавом энерпрайзе в интранете бастион ослабляет безопасность сетевых доступов. На примере: есть сегментированная сеть (подсети разработчиков, админов, много подсетей для разных типов серверов и т.п.). Если используется прямой доступ по ssh без бастиона, то можно пилить точечные сетевые доступы (от сети разработчиков - к дев серверам, от сети админов - к прод серверам и подобное). А если используется бастион, то сетевые доступы предоставляются всем до него и от него на все сервера. Пилить в каждую подсеть по отдельному бастиону - такое себе.
а если говорить про реальность? в чем ослабление то? Ну нормальные аргументы - вот попал разработчик на бастион - с бастиона у него доступ до 2 хостов, зашел дб админ на бастион у него доступ к 3 хостам с бд - в чем ослабление?
источник

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
в чем разница между админить 1 бастион или 1000 000 бастион хостов?
источник

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
это все так же делается двумя кнопнками как и в случае с 1 сервером
источник

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
так чем бастион ослабляет?
у бастион хоста нет какого-либо доступа к хостам за ним, он только проксирует юзера, юзер который не имеет доступа на сервер за бастионом никак туда не попадет - его юзел просто не запровиженен на сервер - это абсолютно обычная реализация нормального бастиона, если где-то сделано по-другому то это ошибка реализации и не более
источник

KS

Konstantin Sverdlov in DevSecOps - русскоговорящее сообщество
Gleb Mekhrenin
так чем бастион ослабляет?
у бастион хоста нет какого-либо доступа к хостам за ним, он только проксирует юзера, юзер который не имеет доступа на сервер за бастионом никак туда не попадет - его юзел просто не запровиженен на сервер - это абсолютно обычная реализация нормального бастиона, если где-то сделано по-другому то это ошибка реализации и не более
я говорил про сетевые доступы. Безопасность — это же комплексная штука и хорошо, когда ее обеспечивают в несколько слоев разные команды: телекомы - выдают сетевые доступы, админы выдают ssh-доступы. Но это все классический подход, оффтопик, не devsecops. Бастион — он только про ssh-доступы (уровень приложений если по модели osi).
источник

KS

Konstantin Sverdlov in DevSecOps - русскоговорящее сообщество
в случае с 1,6М пользователей — конечно не заработает. Особенно учитывая то, что для ssh krypton требует настройки на стороне клиента и не требует доп.настройки на стороне сервера. Но если соотношение обратное — мало клиентов (админы, разработчики) и много серверов, то krypton выглядит норм.
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
>если решается вопрос доступа к серверам все равно нужен бастион
гугл осуждает такую вашу позицию
источник

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
Roman Rusakov
>если решается вопрос доступа к серверам все равно нужен бастион
гугл осуждает такую вашу позицию
это тот гугл у которого только пару лет назад появился tls между сервисами внутри, а до этого трафик снимали все кому не лень? ок да - отличный пример
источник

GM

Gleb Mekhrenin in DevSecOps - русскоговорящее сообщество
с учетом количества железа используемого гуглом там все слишком по-другому. естесвенно если все обмазано различными dpi системами и прочим картинка совсем другая, но тут разговор сейчас не за железо стоимостью в сотни и более тысяч долларов
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Beyond Corp я имею в виду
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Они в белой бумаге расписывают почему они считают что бастионы и ип рестрикшены это мнимая безопасность
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Которая приносит больше вреда чем пользы
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
И мол будущее за sso
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
Ну это на сколько я её понял
источник

V

Vit in DevSecOps - русскоговорящее сообщество
Roman Rusakov
Они в белой бумаге расписывают почему они считают что бастионы и ип рестрикшены это мнимая безопасность
А кто-то не согласен с этим?)
источник