Обновить
11
0

Пользователь

Отправить сообщение

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

Но ведь это не будущее, и не искусственный интеллект ))

ну, про ответсвенность - это в сравнении видно. Все же врач в рантайме принимающий решение или хирург, и прогроммист, который кнопку в 1С плохо сделал...)

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

Короче, мы находимся тут в инфо пузыре - прогроммистов излишне роматнизируем)) Это обычная профессия, для многих скучная, мало чем отличается от бухглалтера. И часто даже меньше отвесвенность)
Просто так получилось, что парикмахер из Читы не может стричь удаленно клиента из Бостона, и получать ЗП выше локального рынка. А прогроммситы - могут (могли)))

Торгуемые товары и услуги – это те, которые могут перемещаться между странами и продаваться на мировом рынке....

(и, кстати, это важно при сравнении зп и уровня жизни в разных странах и упоминать паритет покупательной способности, который любят бедные страны - потому что у них локальные услуги низкие, но и ЗП нищенские)

С точки зрения экономики и рынка труда есть такой параметр - как порог входа.
Сравните - врача, прогроммиста и таксиста)
Вот все любят про такси примеры.
Почему гос-во регулирует эту отрасль?
Потому что порог входа низкий - купить недорогую тачку с пробегом и получить права - почти бесконечный рынок соискателей. Шо происходит без регулирования цены и выдачи лицензий/значков? Рандомные бомбилы тыщами бомбят - цена падает. Но и качесвто слуги - тоже. Бомбила может вообще не поехать в ебеня на вызов или откажется везти вас всего 1300 метров. Бомбилы будут пытаться стоять только во вскусных местах, казино и аэропортах. Далее может произойти такой сценарий - захват отрасли орг преступностью - поделят территорию, взвинтят цены. Тоже ничего хорошего для потребителя, и для новых наивных бомбил - которые могут получить увечья от крепких ребят.

Третий варик - когда всякие агрегаторы претворяются, что они не такси - а только ифнормационные услуги оказывают. Демпингую годами - чтобы выщемить классические таксопарки (посмотрите сколько лет был в минусе Uber) Перекладывают затраты на обслуживание машин на "свободных контракторов" (это откат в 19 век с точки зрения прав работника), которые пашут по 12 часов в сутки, не имеют отпусков и прочих прав , как обычные наёмные сотрудники классического автопарка, сами заправляют, чинят, моют свою машину. Амортизацию тоже забывают учесть)

Поэтому во многих странах прижимают и регулируют эти "информационные сервисы" - заставляют быть обычным такси)). Как и многие другие отрасли.

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

И у прогоромиста даже не спросят за корочки - диплом гарварда, водитеслкое удоствоернеи и даже мед справку))

Предлагаю вам самим подумать, что происходит с емкостью рынка труда "программиста широкого порфиля" и рынка производства бытового мусора массового софта.

Хоть и не принято тут писать тупые бессодержательные каменты, но..ребята - я кайфанул!
От статьи, от каментов.
А то уже совсем деградировал, разочаровался в себе и в людях...)
А тут такое...

P.S. Но это не отменяет того, что хабр уже не торт))

>не хотели вникать в нюансы администрирования

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

Человечство двигается так веками - специализация, сокрытие сложности и движение дальше (с переменным успехом))))

Ну, я в надежде, шо аффтар статьи@onvamneciso даст каменты)

Перелогинился
(не помогло))))

Если что, мне облачные провайдеры не отсегивают за реклму))

Остается 1 аргумент - безопасность данных.

И я бы попорил, где безопаснее для обычного бизнеса.
Кому больше доверять - нанятым одминам своего онпрема или облачнм одминам. Где более крутые спецы и технологии, кто быстрее про...фукает из за дыр, или продаст, украдет данные...))

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

ну а далее каждый бизнес сам решает и считает затраты.
И даже если по расчетам пуьличное облако получается сильно дороже - то всё равно часто затраты на инфру могут составлять не решающую долю, а другие плюсы перевешивают (типовые решения, удобсвто, скорость развертывания, динамические нагрузки, capex vs opex ...)

Кстати еще - надеюсь, никто в 2025 году не вешает паблик IP на виртуалки (EC2) а юзает serverless, API Gateway и lambda или ECS .
Даже bastion (jump) машинки уже щитаются как бы давно нарушением безопасности
Есть более современные методы конфигурить машины, но я даже и ssh не включаю - ибо только ansible terraform, eks, vpn, IaC, GitOps и вот это всё. Никому не нужно чинить машины на лету - есть избыточность и повторяемость - убиваешь мертвую машину, поднимаешь кодом рядом новую (Или автоматически (ASG)), коллектишь метрики и логи во внешние тулы).

Прям вот если мне сильно нужно внутрь виртуалки что-то в проде посмотреть (в кубер ноде - ибо остальное кручу в Managed сервисах (базы, кеши и прочее)) - ну можно временно туда зайти, например через Session Manager, нырнуть в приватную сеть в кубер - подняв временный pod с нужными тулами - вынырнуть в namespace хостовой...)

Ну, или таки если вы все же не кубер юзает, и нужно что то крутить в Ec2 руками или ansible - через VPN конектиться в приватным IP...


Короче - zero operational ))
0 кода и баш портянок.
Вайб yaml погромирование))
И автоматизация на 80% (согласно Парето)

И сразу ответ, кто будет говорить - что вот нынешнее поколение девляпсов ничего не знают про сети, серверное железо, Linux etc - и только мышкой в облаке клацать умеют - это не правда - чтобы клацаць мышкой писать терраформ код - надо все понимать, и я прошел все стадии (голое железо, сети, linux, виртуализацию, контейнеризацию). Облака - это чертовски удобно. И если грамотно финопсить (FinOps) и юзать автоскейлинг- то не намного дороже, чем держать 3 независмых ввода питания и стыка с точками обмена трафиком и промышленное охлаждени и пожаротошение в своем ДЦ штат разных одминов, которые там изобретают свои велосипеды )) Ибо ФОТ - это сущесвенная часть постояннях затрат.

В догонку - использование IMDSv2 (вроде как давно по дефолту) полностью или значительно решает именно этот кейс ?

P.S. На всякий случай даже еще раз проверил)) в продовых машинах - так и есть - юзается IMDSv2

Хочу уточнить все же все условия успешной атаки, но на примере AWS (ибо не спец в яндексе):

>>> 1. Получению первоначального доступа способствует наличие публично доступной виртуальной машины.

Правильно я понимаю, что на самом деле не обязательно EC2 должна иметь Public IP, достаточно чтобы был опубликован наружу ендпоинт до web сервера на виртуалке (через cloudfront и/или ALB) ?

Если так, то в CF/ALB должен быть rule который бы вел на уязвимый path?
Иначе не прокатит...

>>>Для исполнения требуется SSRF или RCE (Remote Code Execution, произвольное выполнение кода).

ну, тут понятно - тут проактивные меры. Ибо безопасность - это процесс. (тесты на уязвимость инфры, контроль трафика)

Кстати WAF помог бы с соответвующей политкой от SSRF или RCE ?

И еще уточнение - на картинке два разных фолдера имеют общий VPC ?
Не знаю, как это матчится для AWS - я просто для каждого проекта юзаю не только отдельный VPC, но и отдельный Account в рамках Organization (это не аккаунт юзера, и не то, что в GCP). Т.е. изоляция полная - и сети и привилегий и вообще всех ресурсов.

>>> При нахождении привилегированного сервисного аккаунта злоумышленник сможет действовать от его лица

>>> IAM Токен – заветная цель, расширяющая возможности злоумышленника. Имея токен с высокими привилегиями, можно управлять облачной инфраструктурой.

Я правильно понял, что в термининах AWS - на test EC2 навешали IAM role с админскими привелегиями (зочем?), да еще и с доступом к продовским ништякам?

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

>разрешение "terraform apply" только из мейна
и дополнительно:

- запрет эплаить с локальных машин на прод (тупо права/креды для людей только рид онли). Креды на запись - только у CI (ну, разумеется у ограниченного круга опытных и ответвенных лиц права на запись будут - но они все равно в обычном режиме должны катить через git/CI/IaС - и лишь в экстренных случаях что-то трогать на проде вручную, а потом устранить дрифт)

- чоткое разделение окружений и прав + аудит (в облаках с этим все шикарно)

- сначала в CI должен быть степ plan в файл, и следующий степ apply из этого файла (после апрува)

- настройте конфиг - чтобы стейт хранился в облаке (S3) + сделайте автобэкап этого S3 в другой регион (можно даже в рид онли контейнер)

- периодический автоматический процесс поиска дрифта (запуск плана - и если что-то уехало - нотификация)

- изменение архитектуры, обновление терраформа или провайдеров - сначало через тестовые окружения

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

- В реальности невозможно покрыть всю инфру на 100% терраформом - 80% это уже хороший результат. Не стращно, что что-то делается руками, скриптами, джобами - но не терраформом - главное это документировать. Просто иногда проще в 10 раз что-то сделать руками (специфические сервисы или настройки), особенно если это делается редко или даже 1 раз при разворачивании нового окружения, ибо кое какие вещи будут вызвать боль, если их пытаться делать терраформ, а потом вносить изменения
Тот самый принцип парето))
Ну, всмысле - не стоит в падать в крайности и фанатизм некоторых догм типа IaC )))

- Юзайте всякие обертки над терраформом для layering и DRY (Dont Repeat Your Self (типа terragrunt, terraspace)

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

Привет из 2025 )
Перешел сегодня на Wayland
Полет нормальный
KDE Plasma 6.3 / Kubuntu 25.04
Интегрированная видюха intel на ноуте - не помню какая)
Халва 2 VSCode работает )
Держу в курсе
-----
P.S.
тула xlsclients показывает, что 0 приложений работают через XWayland
(т.е. все прилаги работают на вяленом напрямую)
(браузеры, slack, Lens, keepassXC, veracrypt, dbeaver, joplin)

>Постарайтесь в первые 6 мес. выбрать из команды своего заместителя,
>который будет заменять вас в отпуске или во время болезни. Хочу
>отметить, что назначение заместителя ничего не имеет общего с
>делегированием задач.

Надеюсь, это "назначение" не принудительно, а по согласию? )
Надеюсь, за это приплачивают? )

>Можно делегировать любую задачу любому
>разработчику (например, отправить вместо себя на встречу).

А вот такое я лично не люблю. С таким же успехом можно попросить окна помыть или сбегать за пивом. Тут надо сразу на берегу оговорить обязанности подчиненных. В зрелых компаниях есть четкая должностная инструкция и/или что-то типа матрицы компетенций/обязанностей. Понимаю, что все трудно учесть и формализовать, но требовать от разрабовать выполнять ваши "лидерские" задачи...ну, такое...)

Ну, ответ на поверхности — зп высококлассного спеца — его время и узко специализированные знания, которых нет в универе и в книжках. Например, 2 восстановления в месяц должны прокормить такого спеца, и эти деньги должны быть больше, чем если бы он на кассе сидел на заправке....). И вы должны понимать, что это сложный медленный процесс, в каждом случае со своими особенностями — на поток не поставишь

Не, я имею ввиду обоснование. На каждый софт, либу, репу. Нужно получить апрув, начиная с безопасников. Они спросят, зачем тебе прикладной софт на этих серверах… и, будут правы. Но, если кому то можно ставить любой софт не на свои личные хосты, а тем более на сервера клиентов, то вопросов нет)

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

Информация

В рейтинге
4 679-й
Зарегистрирован
Активность