И противоречия тут нет. Если вы шифруете на уровне приложения, то данные в нашем гипотетическом логе будут зашифрованы так же. Значит их можно опубликовать - они уже защищены.
Можно провести мысленный эксперимент. Если ваш сервис передает какие-то данные, и вы эти данные параллельно (например, в виде логов) можете выложить в открытом доступе в интернет, то значит вам не нужны сертификаты и TLS. Если не можете публично выложить эти данные - то нужны сертификаты и TLS.
Ведь логика простая. Ваш трафик без проверки сертификата может кто-то прочитать. Не значит, что обязательно прочитает, но может.
Тоже самое с логами обмена в интернете. Если вы их выложили, то это не значит, что их кто-то прочитает. Но может кто-то прочитать.
В обоих случаях это не конкретный субъект, а неопределенная группа субъектов, на которую вы не можете повлиять или даже их как-то идентифицировать.
С логами в интернете даже лучше ситуация. Если они на вашем сервере, и их кто-то получал, вы хотя бы знаете, что их кто-то получал. В случае перехвата http вы даже не знаете, что перехват был.
Я может быть добавлю, что несмотря на то, что браузеры теперь НЕ отправляют первый запрос на http, это в целом мало помогает.
Рассмотрим вариант с браузером. Если злоумышленник может перехватить ваш трафик http, то вполне возможно он может заблокировать ваше соединение по https (если вы подключены через его wifi, или послать tcp reset если он просто подключен вместе с вами к этому wifi), и первый запрос браузера сфйелится, ибраузкр вероятно пошлет его по http. А дальше история с фишингом, про который вы уже рассказали.
Дальше тоже интересно. Даже если у вас вообще будет выключен http на вашем сервере, то ничего не заставит упомянутые интеграции, в которых захардкожен доступ по http, не делать этих запросов по http. То есть то, что они отправляют - все равно сможет быть перехвачено.
Поэтому, хотя выглядит так, что жёстким, но безопасным способом было бы вообще выключить http - это не так. Безопаснее было бы ОСТАВИТЬ http включенным на своей стороне (дальше уже или редирект, или дроп) но в этом случае вы хотя бы будете знать, кто к вам ходит по http, и можете считать, что их данные потенциально скомпрометированы. Может быть как-то уведомлять клиентов или партнёров, что нужно произвести перенастройку.
У документации есть проблема: в ней написано только то, что в ней написано.
Она может быть общей
Она может быть подробной
Она может быть очень подробной
И чем она подробнее, тем сложнее ее читать и понимать. А вести три документации - это очень сложно.
И при этом любая, даже самая подробная дока, скорее всего все равно не отвечает на вопрос "а что если тут будет так, а здесь - эдак, какой будет результат?" Какие-то кейсы конечно могут быть покрыты документацией, но конечно не все.
Поэтому самая полная документация - это и есть код.
И теперь, в век LLM, аналитику не надо его читать. Он может задать конкретный вопрос и получить конкретный ответ. А ещё такая документация не устаревает.
Безусловно, верхнеуровневую доку в проекте можно хранить в виде md, просто для того, чтобы агентам не нужно было загружать контекст из тысяч файлов при любом запросе. Но опять же, для этого есть инструменты, которые делают такой индекс автоматически, его нужно просто обновлять при изменениях в коде.
А что было в этот момент с метрикой количества запросов к базе и алертом "количество запросов к базе на xx% отличается от среднего количества запросов в это время в этот день недели за последний месяц"? Такой себе алерт конечно, он простреливает в дни распродаж, но в эти дни его принимают как должное. А вот когда он стреляет в "обычный день" - он помогает дежурному не ходить в дашборды в поисках аномалий.
Надо отметить, что такой мониторинг подходит для систем, где все стабильно и предсказуемо. Если же у вас релизы по 33 раза в день, в которых постоянно что-то меняется, то он скорее вредный, чем полезный.
Ну завтра (или уже сегодня) будет так: Датчики обнаружили что лобовое имеет шансы запотеть (замеры влажности и температуры) и был включен обдув или подогрев заранее.
Может "уметь писать код" и не обязательно. В каком-то смысле его давно почти никто не пишет.На процессорах выполняется совсем не тот код, который написали разработчики. Они пишут одно, потом это транслируется компилируется, оптимизируется, преобразуется. И в итоге получается машинный код, который выполняется.
Когда разработчик использует какой-то фреймворк - всегда ли он знает, какие библиотечные функции он вызывает внутри себя, и как они работают? А когда использует библиотечные функции? А знает ли, что произойдет с его кодом после компиляции, что останется, что вынкинется? А как команды будут загружаться в конвейер? Что происходит со стеком при вызове функций? Задумывается ли об этом разработчик каждый раз, создавая новую функцию в своем "коде"? Что-то я слабо в это верю. Есть некоторые разработчики, которые успешно программируют на всяких высокоуровневых языках, и про это вообще никогда не задумывались.
Просто раньше мы начинали писать вместо 0010010 mov ax,bx. Потом вместо move ax,bx стали писать что-то вроде let price=5. Теперь пишем "запомни стоимость". Как пример. Плохо это или хорошо? Да это уже происходит десятки лет - вы пишите одно, а "работает" на самом деле совсем другое.
Что у вас с навыком написания кода на asm? А бинарнную программу на перфокарте давно вводили? Навык утерян? Это вам мешает?
Так что вы вроде и правы. В сегодняшних реалиях. А в завтрашних это может быть будет нормой.
недопониманием между нейросетью, кодом и человеком
В чем разница между недопониманием между заказчиком, аналитиком и разработчиком, который пишет сам, без ИИ?
Если архитектор, декомпозировал какую-то сложную задачу на более мелкие, а разработчики реализовали части задач, стал ли архитектор понимать, КАК ИМЕННО они это реализовали? Если вместо людей-разработчиков код написала нейронка - что поменялось для продукта в целом?
Опять же, большой вопрос - что понимать под "разработкой с помощью ИИ".
Если нужно сделать "сайт по продаже кроссовок", и вместо проработки задачи написать в нейронку "сделай мне сайт по продаже кроссовок", то получится "какой-то сайт по продаже кроссовок". Не тот, что хотел заказчик. Ведь он не сказал, что он хотел.
Но с другой стороны в 90% случаев заказчик и не знает, что именно он хочет.
И человек-разработчик тоже не знает. Так что разницы как будто никакой нет.
Ну теперь будут учения проводить по отключению независимых вводов.
Или нет.
В целом могу понять эту боль. Стоит у тебя какой-то девайс/софт, который должен переключить на резервную схему. Но в час Х, когда нужно переключить, переключение не происходит. Или в железе релюха залипла, или в софте старая конфигурация осталась, или ещё что-то.
Единственный способ проверить, что все случится - провести тестовое отключение. Но есть шанс, что что-то пойдет не так, поэтому такие тестовые отключения не любят.
А когда у тебя двойной или тройной резерв, то тестировать его работоспособность ещё сложнее. Например, у тебя три независимых линии питания. Выключатель любую - все работает. А включаешь две - последняя выгорает от перегрузки. И когда на двух появляется питание - у тебя релюха какая нибудь прикипела. Это все кажется не сложным, и легко решаемым, когда знаешь входные данные аварии. Но она же внезапная.
Тут затронули тему того, что для простых решений можно и самому написать, а вот если нужно что-то гибкое, позволяющее построить сложные архитектуры - то лучше посмотреть на готовые решения.
Я бы тут подискутировал. Разобраться в продукте, который "может всё" чаще даже сложнее, чем писать код на "всем понятном питоне или го".
Потому что питон и го - условно одинаковые, и широко распространены. А какой-то вендорский продукт работает "как-то так, как задумал вендор". Может быть так, как вам надо, а может быть и нет. То есть помимо того, что нужно как-то понять логику его работы (а "учебника по биллингу" скорее всего нет, и уж точно нет "другого учебника, если этот непонятный", в отличие от учебников по питону), так ещё и внести изменения скорее всего будет не очень просто.
Так что если посмотреть с этой стороны, то выглядеть всё может ровно наоборот - с вендорский решением легко начать работать, а вот потом могу возникнуть сложности (но, конечно же, не обязательно они возникнут)
Если я делаю заказную разработку своего биллинга, а потом разработчик уходит - это боль. Если я сам разработчик своего биллинга - то проблемы как будто нет. Если я покупаю продукт у вендора - то проблемы с уходом разработчика нет, но есть проблема с гибкостью, ну и потенциальный уход вендора.
«Сокращаем время расследования инцидентов с часов до минут».
Тоже хочется в ответ на такое крикнуть в монитор: А как измеряли? А если будет больше минут, вернёте деньги или возместить ущерб? А если нет, то за вообще за свои слова отвечаете?
Но в целом статья в точку. Короме некоторых моментов.
Возможно фразу "человек становится ценнее" нужно читать так: В среднем человек в компании становится ценнее, потому что всех не ценных, кого можно заменить на ИИ - заменят на ИИ.
Очень много вопросов после прочтения. Больше, чем ответов.
Почему, когда контрол-плейн недоступен, "бизнес теряет деньги"? Его приложения не зависят от контрол-плейна.
Почему есть доступ по ssh на мастер узел? Что с безопасностью?
Почему сертификат не обновился самостоятельно? Почему не было алертов за пару недель?
Почему вообще может закончиться место на диске и мониторинг молчит?
Почему бы не перегружать кубелет сколько мне вздумается, ведь логи от предыдущих запусков никуда не денутся.
Начинал читать статью как интересный кейс, а оказалось все для вывода - приходите к нам и мы расскажем как делать правильно.
С другой стороны хорошо что есть такие курсы, и все больше людей начнут делать в итоге правильно. И не придется беспокоиться во вторник в 14:00 о поломке etcd, которая вообще не должна была случиться.
Nginx ingress controller не формирует конфигурации, где в rewrite есть вопросик "?"
То есть уязвимость скорее формальная, чем реальная.
Исключение составляют configuration snippets, где можно написать что угодно. Но ими и так можно было произвольным образом сломать контроллер, их наличие само по себе можно рассматривать как уязвимость.
Согласен с вами.
И противоречия тут нет. Если вы шифруете на уровне приложения, то данные в нашем гипотетическом логе будут зашифрованы так же. Значит их можно опубликовать - они уже защищены.
Ну это вопрос философский.
Можно провести мысленный эксперимент. Если ваш сервис передает какие-то данные, и вы эти данные параллельно (например, в виде логов) можете выложить в открытом доступе в интернет, то значит вам не нужны сертификаты и TLS. Если не можете публично выложить эти данные - то нужны сертификаты и TLS.
Ведь логика простая. Ваш трафик без проверки сертификата может кто-то прочитать. Не значит, что обязательно прочитает, но может.
Тоже самое с логами обмена в интернете. Если вы их выложили, то это не значит, что их кто-то прочитает. Но может кто-то прочитать.
В обоих случаях это не конкретный субъект, а неопределенная группа субъектов, на которую вы не можете повлиять или даже их как-то идентифицировать.
С логами в интернете даже лучше ситуация. Если они на вашем сервере, и их кто-то получал, вы хотя бы знаете, что их кто-то получал. В случае перехвата http вы даже не знаете, что перехват был.
Спасибо за интересный анализ.
Я может быть добавлю, что несмотря на то, что браузеры теперь НЕ отправляют первый запрос на http, это в целом мало помогает.
Рассмотрим вариант с браузером. Если злоумышленник может перехватить ваш трафик http, то вполне возможно он может заблокировать ваше соединение по https (если вы подключены через его wifi, или послать tcp reset если он просто подключен вместе с вами к этому wifi), и первый запрос браузера сфйелится, ибраузкр вероятно пошлет его по http. А дальше история с фишингом, про который вы уже рассказали.
Дальше тоже интересно. Даже если у вас вообще будет выключен http на вашем сервере, то ничего не заставит упомянутые интеграции, в которых захардкожен доступ по http, не делать этих запросов по http. То есть то, что они отправляют - все равно сможет быть перехвачено.
Поэтому, хотя выглядит так, что жёстким, но безопасным способом было бы вообще выключить http - это не так. Безопаснее было бы ОСТАВИТЬ http включенным на своей стороне (дальше уже или редирект, или дроп) но в этом случае вы хотя бы будете знать, кто к вам ходит по http, и можете считать, что их данные потенциально скомпрометированы. Может быть как-то уведомлять клиентов или партнёров, что нужно произвести перенастройку.
Скорее 1997
Ох, и правда 30 лет прошло...
А кто сказал что в документации есть слово "правильный"?
Вы за собой никогда доку не исправляли, потому что там что-то было "не совсем правильно написано"?
У документации есть проблема: в ней написано только то, что в ней написано.
Она может быть общей
Она может быть подробной
Она может быть очень подробной
И чем она подробнее, тем сложнее ее читать и понимать. А вести три документации - это очень сложно.
И при этом любая, даже самая подробная дока, скорее всего все равно не отвечает на вопрос "а что если тут будет так, а здесь - эдак, какой будет результат?" Какие-то кейсы конечно могут быть покрыты документацией, но конечно не все.
Поэтому самая полная документация - это и есть код.
И теперь, в век LLM, аналитику не надо его читать. Он может задать конкретный вопрос и получить конкретный ответ. А ещё такая документация не устаревает.
Безусловно, верхнеуровневую доку в проекте можно хранить в виде md, просто для того, чтобы агентам не нужно было загружать контекст из тысяч файлов при любом запросе. Но опять же, для этого есть инструменты, которые делают такой индекс автоматически, его нужно просто обновлять при изменениях в коде.
А что было в этот момент с метрикой количества запросов к базе и алертом "количество запросов к базе на xx% отличается от среднего количества запросов в это время в этот день недели за последний месяц"? Такой себе алерт конечно, он простреливает в дни распродаж, но в эти дни его принимают как должное. А вот когда он стреляет в "обычный день" - он помогает дежурному не ходить в дашборды в поисках аномалий.
Надо отметить, что такой мониторинг подходит для систем, где все стабильно и предсказуемо. Если же у вас релизы по 33 раза в день, в которых постоянно что-то меняется, то он скорее вредный, чем полезный.
Ну или вариант - через 5 лет мотор стёрся до дырок, потому что чугунных давно уже не делают.
Ну завтра (или уже сегодня) будет так: Датчики обнаружили что лобовое имеет шансы запотеть (замеры влажности и температуры) и был включен обдув или подогрев заранее.
Может "уметь писать код" и не обязательно. В каком-то смысле его давно почти никто не пишет.На процессорах выполняется совсем не тот код, который написали разработчики. Они пишут одно, потом это транслируется компилируется, оптимизируется, преобразуется. И в итоге получается машинный код, который выполняется.
Когда разработчик использует какой-то фреймворк - всегда ли он знает, какие библиотечные функции он вызывает внутри себя, и как они работают? А когда использует библиотечные функции? А знает ли, что произойдет с его кодом после компиляции, что останется, что вынкинется? А как команды будут загружаться в конвейер? Что происходит со стеком при вызове функций? Задумывается ли об этом разработчик каждый раз, создавая новую функцию в своем "коде"? Что-то я слабо в это верю. Есть некоторые разработчики, которые успешно программируют на всяких высокоуровневых языках, и про это вообще никогда не задумывались.
Просто раньше мы начинали писать вместо 0010010 mov ax,bx. Потом вместо move ax,bx стали писать что-то вроде let price=5. Теперь пишем "запомни стоимость". Как пример. Плохо это или хорошо? Да это уже происходит десятки лет - вы пишите одно, а "работает" на самом деле совсем другое.
Что у вас с навыком написания кода на asm? А бинарнную программу на перфокарте давно вводили? Навык утерян? Это вам мешает?
Так что вы вроде и правы. В сегодняшних реалиях. А в завтрашних это может быть будет нормой.
В чем разница между недопониманием между заказчиком, аналитиком и разработчиком, который пишет сам, без ИИ?
Если архитектор, декомпозировал какую-то сложную задачу на более мелкие, а разработчики реализовали части задач, стал ли архитектор понимать, КАК ИМЕННО они это реализовали? Если вместо людей-разработчиков код написала нейронка - что поменялось для продукта в целом?
Опять же, большой вопрос - что понимать под "разработкой с помощью ИИ".
Если нужно сделать "сайт по продаже кроссовок", и вместо проработки задачи написать в нейронку "сделай мне сайт по продаже кроссовок", то получится "какой-то сайт по продаже кроссовок". Не тот, что хотел заказчик. Ведь он не сказал, что он хотел.
Но с другой стороны в 90% случаев заказчик и не знает, что именно он хочет.
И человек-разработчик тоже не знает. Так что разницы как будто никакой нет.
Ну теперь будут учения проводить по отключению независимых вводов.
Или нет.
В целом могу понять эту боль. Стоит у тебя какой-то девайс/софт, который должен переключить на резервную схему. Но в час Х, когда нужно переключить, переключение не происходит. Или в железе релюха залипла, или в софте старая конфигурация осталась, или ещё что-то.
Единственный способ проверить, что все случится - провести тестовое отключение. Но есть шанс, что что-то пойдет не так, поэтому такие тестовые отключения не любят.
А когда у тебя двойной или тройной резерв, то тестировать его работоспособность ещё сложнее. Например, у тебя три независимых линии питания. Выключатель любую - все работает. А включаешь две - последняя выгорает от перегрузки. И когда на двух появляется питание - у тебя релюха какая нибудь прикипела. Это все кажется не сложным, и легко решаемым, когда знаешь входные данные аварии. Но она же внезапная.
Правильная формулировка: Число выявлений киберпреступлений сократилось почти на 120 тысяч
Тут затронули тему того, что для простых решений можно и самому написать, а вот если нужно что-то гибкое, позволяющее построить сложные архитектуры - то лучше посмотреть на готовые решения.
Я бы тут подискутировал. Разобраться в продукте, который "может всё" чаще даже сложнее, чем писать код на "всем понятном питоне или го".
Потому что питон и го - условно одинаковые, и широко распространены. А какой-то вендорский продукт работает "как-то так, как задумал вендор". Может быть так, как вам надо, а может быть и нет. То есть помимо того, что нужно как-то понять логику его работы (а "учебника по биллингу" скорее всего нет, и уж точно нет "другого учебника, если этот непонятный", в отличие от учебников по питону), так ещё и внести изменения скорее всего будет не очень просто.
Так что если посмотреть с этой стороны, то выглядеть всё может ровно наоборот - с вендорский решением легко начать работать, а вот потом могу возникнуть сложности (но, конечно же, не обязательно они возникнут)
Если я делаю заказную разработку своего биллинга, а потом разработчик уходит - это боль. Если я сам разработчик своего биллинга - то проблемы как будто нет. Если я покупаю продукт у вендора - то проблемы с уходом разработчика нет, но есть проблема с гибкостью, ну и потенциальный уход вендора.
В общем всё не так однозначно. И да и нет.
Только днём. Ночью - нет.
Тоже хочется в ответ на такое крикнуть в монитор: А как измеряли? А если будет больше минут, вернёте деньги или возместить ущерб? А если нет, то за вообще за свои слова отвечаете?
Но в целом статья в точку. Короме некоторых моментов.
Возможно фразу "человек становится ценнее" нужно читать так: В среднем человек в компании становится ценнее, потому что всех не ценных, кого можно заменить на ИИ - заменят на ИИ.
Очень много вопросов после прочтения. Больше, чем ответов.
Почему, когда контрол-плейн недоступен, "бизнес теряет деньги"? Его приложения не зависят от контрол-плейна.
Почему есть доступ по ssh на мастер узел? Что с безопасностью?
Почему сертификат не обновился самостоятельно? Почему не было алертов за пару недель?
Почему вообще может закончиться место на диске и мониторинг молчит?
Почему бы не перегружать кубелет сколько мне вздумается, ведь логи от предыдущих запусков никуда не денутся.
Начинал читать статью как интересный кейс, а оказалось все для вывода - приходите к нам и мы расскажем как делать правильно.
С другой стороны хорошо что есть такие курсы, и все больше людей начнут делать в итоге правильно. И не придется беспокоиться во вторник в 14:00 о поломке etcd, которая вообще не должна была случиться.
Nginx ingress controller не формирует конфигурации, где в rewrite есть вопросик "?"
То есть уязвимость скорее формальная, чем реальная.
Исключение составляют configuration snippets, где можно написать что угодно. Но ими и так можно было произвольным образом сломать контроллер, их наличие само по себе можно рассматривать как уязвимость.
Очевидная польза от статей про ИИ - они выдавили статьи про блокчейн, а точнее про очередной-коин.
У ИИ есть хотя бы прикладное применение, в отличие от коинов.