• Shanmugha@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    11 hours ago

    *and all those environments come with admin teams (devops, sysops, call them whatever) actually good at what they do. Because I have a long list of things to vent about exactly because:

    • you’re a dev, so fight us for access and permissions (edit: that I already have ssh access to prod servers and thus could wreak havok any moment if I wished to is completely ignored)
    • here’s a botched something you asked. It is not configured/improperly configured - well, who da fuq cares. Let’s have another kanban card for fixing this
    • zqps@sh.itjust.works
      link
      fedilink
      arrow-up
      5
      ·
      10 hours ago

      Most of the damage is done with good intentions.

      Recently one of our devs was caught running Chrome portable (because he wasn’t given admin access), where he logged in to his personal google account and saved his company credentials, where they were promptly synced to his personal malware-infested home system and ended up in a paid dataset on the darknet. IT Security, InfoSec and Governance policies have to be written with this kind of employee behaviour in mind.

      Incidentally him and his team had just complained loudly about MFA being required for our critical apps.

      • Shanmugha@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 hour ago

        Well, that is bad all over. And also can be seen as an evidence towards “if someone requires access that does not look suspicious, give it to them”: he wasn’t given access, so he went another way and fucked up spectacularly. On the other hand, though:

        • if it is a company machine, then not having admin access can be expected
        • I would expect that “do not ever use personal accounts for work and vice versa” does not need reminding, but here we are
        • yeah, the rules should account for malicious behaviour, intended and not