"persoonlijke laptop" - je service veiligheid moet je niet al te hard afhankelijk maken van beperkt controleerbare endpoints.

Het is (haast) altijd mogelijk om admin rechten te krijgen op een persoonlijke laptop.
Zorg dat dat je je diensten zodanig bouwt dat de schade die een client device kan aanrichten beperkt is.

Zorg dat je efficiente recovery mogelijkheden van data op servers die door de clients beschreven wordt. (fileshares, git repo's e.d.) . Ook zonder kwaadwillendheid komen "oeps" momenten voor, dus dat is altijd handig.
En ga denken in de richting van thin clients - dan maakt het een heel stuk minder uit of iemand admin is op een "thin client device" .

Hoewel ik er niks vanaf weet kreeg ik met het zoeken via google de nodige links.
Geen idee of het de juiste zijn.
Maar probeer eens te zoeken op "limit sudo access"

Waarom worden ze al gegeven als er nog niet over de veiligheid van het netwerk is gedacht?

|Als het hun werk-laptop is, waarom dan nog 'beveiligen' tegen zichzelf? Als ze em stuk configureren, gewoon opnieuw inspoelen. Je zou toch mogen verwachten dat die developers een beetje snappen waar ze me bezig zijn.

Mijn advies is om vooral te focussen op het (laten) opleiden van ontwikkelaars hoe zij veilig kunnen werken. Daar worden het ook betere ontwikkelaars van.

Proberen privileges op hun "eigen" werkstation in te perken, leidt er in de praktijk toe dat ze binnen de korste keren workarounds vinden of dat ze een andere werkgever zoeken. Ook is het belangrijk dat de relatie tussen beheerders goed blijft, want hun werkzaamheden vervloeien steeds meer; BofH beheerders helpen bedrijven zelden vooruit (wat niet wil zeggen dat je elke ontwikkelaar maar een vrijbrief moet geven in je domein). Neem wel maatregelen voor het geval dat er iets fout gaat, zoals netwerksegmentatie. Leg je beleid vast, sta open voor suggesties maar wees ook streng als medewerkers de vastgestelde regels aan hun laars lappen.

Van te voren definiëren welke commands nodig zijn voor het bedrijf en de werkzaamheden
Ik raad je het volgende artikel aan voor meer informatie omtrent de mogelijkheden met sudo
https://ubuntuforums.org/showthread.php?t=1132821

Na het aanleggen van de lijst kun je via chattr +i /etc/sudoers het onmogelijk maken voor ze om zelf aan de permissie's te sleutelen.

Maar het blijft altijd een risico dit is niet 100% waterdicht. Soms hebben programma's namelijk meer rechten los van de gebruiker en kun je via via weer commands uitvoeren ook al is de gebruiker beperkt.

Op een Ubuntu laptop kun je niet zo veel verpesten op een netwerk als op een Windows machine, het risico op malware is minimaal. Ik denk dat ze het wel uit hun hoofd laten een probleem te veroorzaken als daardoor hun laptop opnieuw wordt geinstalleerd. Gewoon een waarschuwing geven.

Waarom zou een ontwikkelaar geen root toegang mogen hebben op zijn/haar "persoonlijke" laptop? Dat veranderd ook helemaal niks aan wat ze kunnen aanrichten in het netwerk, staat er compleet los van.

Dat is onjuist. Zonder root privileges kan de ontwikkelaar, of door hem/haar gestarte malware, geen ARP-spoofing attacks uitvoeren, niet in promiscuous mode sniffen, geen firewall rules wijzigen, software niet op poorten onder 1024 laten luisteren, geen system libraries vervangen of wijzigen etc.

Het zijn developers, geen schoolkinderen, er bestaat ook nog zoiets als wederzijds vertrouwen. Dit lijkt uit te gaan van de ouderwetse beheer filosofie waarbij de beheerder dicteert wat goed is. (Bij ons heeft iedereen admin rechten op zijn / haar Macbook, gaat prima)

Misschien wel de meest onzinnige opmerking in lange tijd.
De kans dat een developer op een Linux computer schade aanricht in een netwerk is vele malen groter dan de kans dat iemand dat doet van een Windows computer zonder beheers rechten.

Developers zijn over het algemeen geen beheerders, wat extra rechten hier en daar om hun software te laten functioneren is niet uitgesloten. Waarom denk je dat er zoveel software is dat te veel rechten nodig heeft op welk systeem dan ook?
De meeste software developers zijn niet primair bezig met beveiliging.

Maar wat developen die developers dan, dat ze daar root rechten voor nodig hebben?
Voor veel development werk is dat helemaal niet nodig.
Wellicht is er iets nodig als het een complex systeem is wat getest moet worden, maar dan is het wellicht handiger om
een aparte testomgeving te maken bijvoorbeeld als virtual machine ergens op een (cloud)server, waar je de root
rechten op geeft. Het is dan tevens gemakkelijk om images of snapshots te maken om na een test de hele machine
weer terug te zetten naar de beginsituatie. De "laptop van de developer" kan dan niet zo gemakkelijk in de soep lopen
wat de productiviteit verhoogt.

Pas op dat je de root rechten niet alleen geeft omdat de developers denken dat ze daarmee meer status krijgen.
Je hoort dat vaak in die kringen en het heeft weinig nut. Net zoals het geven van meer rechten aan beheerders, ik
heb zelf nooit meer rechten op mijn eigen werkstation dan iedere andere medewerker en als ik iets moet maken/testen
wat als beheerder draait (bijvoorbeeld een installatieprocedure) doe ik dat op een andere machine als VM die ik zo
weer kan resetten naar "kaal". Anders is het niet eens een goede test.

Dat is pas een onzinnige opmerking! Hoewel, die Linux developers hebben natuurlijk wel meer kennis van zaken.

$ man sudoers

Het is niet bepaald de makkelijkst leesbare man page die er is, maar hij vertelt je wel wat er allemaal mogelijk is met sudo. Je kan veel fijnmaziger rechten regelen dan botweg iemand lid maken van de sudo-groep zodat die alles mag. Je kan bijvoorbeeld groepen users en groepen commando's definiëren en die op dat niveau elkaar koppelen, en bij de commando's is het mogelijk om rechten te koppelen aan specifieke commandline-argumenten. Commando's worden niet per se als root uitgevoerd maar je kan ook definiëren als welke andere user iets uitgevoerd mag worden.

Wat de man page lastig te lezen maakt is dat EBNF-notatie wordt gebruikt in de syntaxbeschrijving en voorbeelden dun gezaaid zijn. Je moet daardoor zelf vanuit abstracte beschrijvingen de praktische mogelijkheden construeren. Dat kost inspanning, maar het is de studie-inspanning waard.

E.e.a. is afhankelijk van de reden waarom ze 'elevated' rechten moeten hebben. Moeten ze een bepaald programma met die rechten draaien (wat niet slim is) kan je het 'setuid' bitje zetten. Andere zaken moet je goed in kaart brengen en voor die commando's sudo rechten geven.

Door enkel root te gebruiken op momenten dat je het werkelijk nodig hebt, en niet by default.

Wat een onzinnig ''advies''.

Developers die Superuser moeten worden om zelf van alles te installeren remote desktops gebruiken firewalls omzeilen.
Het is de wijze waarop de onveiligheid ontstaat.
Het toont tevens een mismatch tussen de diensten op infrastructuur naar Developers.

Er is iets goed mis als applicatie bouwers root rechten nodig hebben.
Heb je het over onderzoekers naar nieuwe tools op infrastructuur dan is de vraag waarom dat niet met de verantwoordelijken voor infrastructuur kan.

Je komt uiteindelijk in de situatie dat iets wat onverantwoord is om uit te rollen opgelegd wordt om uit te rollen omdat het werkt.

Helemaal mee eens! Er zijn dus heel veel developers die "Even snel een SSH tunneltje maken" met TCP en X11 forwarding aan en alle mogelijke gevolgen van dien (waarvan ik dus er zelfs nog veel zonder public / private key authenticatie zie werken!). Helaas zijn er net zoals veel developers ook veel lakse IT beheerders, welke ook geen Administrator rechten zouden moeten hebben :-D. Zelf heb ik ze nooit nodig, alleen voor beheer taken en vanuit die logica dienen developers ook te programmeren. Ik heb gebruikers dus gewoon met aangepaste gdm configuratie zien draaien, waardoor ze als root op hun desktop / laptop konden inloggen...dat was handiger...

Verder dient software tevens nooit op een poort lager dan 1024 te draaien, want de meeste daarvan zijn al voor andere doeleinden gereserveerd, tenzij het bijv. een website is. Desondanks gebruik ik zelf iptables voor een poort redirect en draai ik apache / nginx op 8080 en 8443 zodat het geen root rechten nodig heeft. Er zijn zoveel mogelijkheden om een systeem zoveel veiliger en stabieler te laten draaien, maar helaas gaat bij velen laksigheid en gemak voor veiligheid.

Het klopt dat er bijna altijd een mismatch is tussen standaard kantoor werkplekken en mensen met development (of vergelijkbaar technische ) functie.

Maar in sommige gevallen kan ik heel goed begrijpen dat een developer met regelmaat root rechten nodig heeft.

Ik schrijf nog wel eens wat scriptjen (development met kleine 'd') - en dan heb je de ene of de andere module nodig .
Het is heel erg prettig als die op de standaard plek vanuit de OS vendor repository geinstalleerd wordt , meteen met alle dependencies.
Daarvoor moet je (als root) dus de package (en z'n dependencies) installeren - (apt-get install <bla> , yum install <bla> ) .

Ik kan niet "alles wat nodig is" tevoren bepalen - dat is waarom het ontwikkeling is. En zelfs als ik alles uit de distro zou installeren zou ik nog een niet-distro module kunnen tegenkomen die ik wil gebruiken (in plaats van voor die code ook weer zelf het wiel uit te vinden ). Ook zo'n module heb ik dan graag in /usr/local , en niet in /home/mijnuser/lib , met alle gezeur om zoekpaden aan te geven .

Misschien gaat het als een service draaien, en moet je de systemd (of init scripten) netjes uitwerken - dat test je alleen maar goed als root .

Dat wil helemaal niet zeggen dat die scripten in de eindsituatie als root gaan draaien, of op een priviliged poort luisteren.
Maar wel dat ik gaande het development met regelmaat dingen als root moet doen .

Alleen al bekijken van webserver logs vereist ook al root rechten op veel installaties.

In die context vind ik het heel begrijpelijk dat ontwikkelaars op de één of andere manier een werkplek hebben met voldoende rechten.
Het zou niet de eerste omgeving zijn trouwens waar de ontwikkelaar het 'echte' werk doet in een VM die weer op een 'standaard KA werkplek' .


Dan verschuif je toch alleen de vraag ? "verantwoordelijken voor infrastructuur die tools onderzoeken" hebben óók ruim meer rechten nodig dan standaard KA . Dat is hetzelfde beestje als 'ontwikkelaar' met een andere naam.


Die conclusie volgt helemaal niet uit het feit dat ontwikkelaars nog wel eens extra rechten nodig hebben.

Een packet sniffer bijvoorbeeld is helemaal geen normale tool als alles klaar en getest is. Maar de sniffer is wel bijzonder vaak nodig tijdens de ontwikkel (of test) fase van dingen. Dat die tool gevraagd wordt door een ontwikkelaar of "verantwoordelijke voor infrastructuur" wil niet zeggen dat de tool op elke end client geinstalleerd gaat worden bij deployment.

Deze uitleg van Canonical, Ltd. er naast leggen, maakt de manpage iets begrijpelijker:

https://help.ubuntu.com/community/Sudoers

De hulplijn uit de sudoers manpage zelf:



Als je een echt leesbaar boek prefereert, kijk dan op:

https://www.sudo.ws/

Sudo Main Page: Documentation >> Sudo Mastery Book, 2nd Edition

Get print or DRM-free ebook.

https://www.tiltedwindmillpress.com/product/sudo-mastery-2nd-edition/

Er zijn al twee goede vragen gesteld:
- waarom vertrouw je de ontwikkelaars niet?
- waarom is sudo nodig?

en daarnaast zou ik graag willen toevoegen:
- waarom is je netwerk zo ingericht dat een laptop die niet door het officiële systeembeheer beheerd wordt een gevaar is?

Geef je ontwikkelaars een eigen subnet zodat ze de boekhouding niet kunnen vernielen!

- is de Ubuntu laptop met UEFI secure boot geinstalleerd?
- is de UEFI firmware wel van een wachtwoord voorzien?
- is het boot volume wel van een LUKS partitie voorzien?

Immers, anders valt de sudo config eenvoudig te omzeilen...


Dat is nog wel het grootste mysterie bij deze vraagstelling...


- hebben de ontwikkelaars wel een geisoleerd testsysteem?

Waarom developers root rechten nodig hebben op hun persoonlijke Ubuntu laptop is heel simpel.
Ik wil een andere IDE, sudo apt install vscode
Ik heb een library nodig; sudo apt install libssl-dev
Ik wil lokaal een dev postgres database hebben: sudo apt install postgres
etc.

Als ik als developer niet op mijn persoonlijke development machine mag installeren wat ik wil zonder daar via 3 managementlagen toestemming voor te vragen, dan kom ik niet developen in jouw toko.

(a) Je geeft nogal knullige, kleinschalige voorbeelden. (b) Als je netwerk niet kan omgaan met werkstations met root rechten, die worden aangesloten, dan ben je sowieso vroeg of laat de klos.

Een ontwikkelaar die locale librarie's nodig heeft om te ontwikkelen is aan het ontwikkelen aan een OS specifieke applicatie, daarvoor richt je dan een container of virtueel systeempje voor in op je werkplek/laptop ipv dat je het risico neemt dat je werkplek/laptop onbruikbaar wordt.

VSCode heeft daar alles voor in huis, dus je krijgt op je laptop: kvm/docker en je kunt lekker spelen zonder je werkplek/laptop open te hoeven zetten.

Happy coding...

Hmm. Is er dan geen bereidheid om samen te werken, op tijd af te stemmen en elkaars argumenten serieus te nemen, en geen kwaliteitscontrole in de organisaties die jij kent? Je kan dit soort situaties namelijk heel makkelijk voor zijn door op tijd te laten weten wat eraan komt en op tijd te luisteren naar elkaars zorgen, bezwaren en opmerkingen, en om die serieus te nemen en te doen wat nodig is om de bezwaren weg te nemen. Als je op tijd naar elkaar luistert is de kwaliteit van de uiteindelijke oplossing trouwens meestal beduidend beter dan wanneer je dat niet doet.

Je eindconclusie als de soll is inderdaad waar het heen zou moeten gaan. De ist is weerbarstiger.

Je hebt de os flaming en open source ptomorie mogelijk gevolgd, het is een toonbeeld van de hakken in het zand en vooral niet naar een ander willen luisteren.

De problemen zitten in de leefcysclus van applicaties. Het woord applicatie wordt gebruikt waarbij ieder een ander beeld hanteert. Dat gaat verder in bi Analytics waarbij met ai ook niemand kennelijk weet waar het om gaat. Als er maar grote projecten voor veel geld gestart kunmen en worden. Een beetje in het verlengde dat smart blockchain de oplossing is voor al uw It problematiek.

Plannen vraagt ook om een vertrouwen dat er voor hetzelfde doel gewerkt wordt. Dat zie je te vaak geschonden worden.

Kortom, even terug naar de vraag van TS:

Een en ander is moeilijk te beantwoorden zonder context. Waarschijnlijk werk je bij een kleine tot middelgrote software leverancier, anders zou je een beheerafdeling hebben die deze vraag kan beantwoorden. Dit is natuurlijk een aanname.
Er wordt hierboven van alles geroepen dat binnen context best samenhangend is. Im Gross und Gans; kijk naar je netwerk. Je geeft aan dat er geen schade aangericht mag worden in je netwerk. Laat je ontwikkelaars dan met hun geroote laptops lekker in een (OTA)ontwikkel, test, acceptatie omgeving rondrommelen. Scheid deze van je (P)productie.

Maak de Acceptatie omgeving gelijkend aan Productie. Stel voor je productieomgeving vast waar je kroonjuwelen zich bevinden, voer een business impact en een risicoanalyse uit, en bescherm je spulleboel zodanig dat die risico's tot een acceptabel niveau worden teruggebracht.

Als daarbinnen past dat de developers rootrechten hebben op hun laptops (en dat lijkt me logisch gezien ze gewoon met libraries moeten kunnen experimenteren) dan maak je daar een beleid voor. In dat beleid leg je ook vast dat ze met andere accounts moeten werken op bedrijfskritische systemen. Die natuurlijk dichtgetimmerd zijn conform geldend hardeningbeleid met selinux/apparmor en waarop je alleen met een sterk geauthenticeerd ldap account kunt inloggen (of wat je maar verzint op basis van je risicoanalyse).

Informatiebeveiliging is specifiek en altijd contextafhankelijk. Op basis van je vraag kan ik je geen goed concreet antwoord geven. Het hangt echt van je specifieke situatie af.

Begin eerst eens met het inrichten van een risicomanagementproces, want dit is echt volkomen verkeerd om.

Een 2e netwerkomgeving maken waarin de developers naar hartelust kunnen sudo'en.
Geen gevaar voor de rest.
Als de developer op het "normale" netwerk iets wil doen, dan kan hij daar niet
op met zijn developer account. En dus inloggen met zijn sudo-loos account.

Je moet beveiliging van je infra niet zoeken in de beveiliging van de aangekoppelde devices zoals lap- en desktops.
Zorg ervoor dat op je storage de ACL's op orde zijn en laat vooral root daar niet kunnen schrijven, al je (netwerk) devices die je zelf onder volledige controle hebt gepatched zijn.

M.a.w. stel dat er een kwaadwillende een device aan je netwerk koppeld dat je services dan nog steeds veilig zijn.

Nou, nee, de ist hoeft niet weerbarstig te zijn, die heb ik volop in werkelijkheid meegemaakt. Hoe? Door het gewoon te doen. Besef dat de meeste mensen van nature een behoorlijk coöperatieve instelling hebben die vanzelf boven komt drijven als ze met een coöperatieve instelling worden benaderd. Niet iedereen, maar een meerderheid wel.
Als mensen hakken in het zand zetten is dat meestal een reactie op iets. Als jij die reactie opvallend vaak meemaakt, zeker als dat niet beperkt is tot de context van één verziekte organisatie, dan zit het er dik in dat het een reactie is op iets dat jij zelf doet. Kijk eens heel kritisch naar je eigen aandeel in de interactie met andere mensen, wie weet valt daar wel heel veel te winnen.

Dat lijkt me een ander voorbeeld van gebrekkige communicatie die tot problemen leidt. Waarom zijn de doelen niet duidelijk? Omdat mensen dat memo van driekwart jaar geleden allang vergeten zijn, misschien? Omdat mensen die met taaie deelproblemen bezig zijn nou eenmaal daar hun volle aandacht voor nodig hebben en dan moeilijk tegelijk ook nog allerlei grote lijnen in het oog kunnen houden, misschien? Zijn er mensen die wat makkelijker afdwalen dan anderen die er wat actiever aan herinnerd moeten worden dan anderen, misschien?

Bewustzijn van doelen moet actief levend worden gehouden. Informele praatjes waarin ze gerelateerd kunnen worden aan waar mensen mee bezig zijn zijn daarvoor vermoedelijk een stuk effectiever dan allerlei formele mededelingen. Managers die veel rondlopen en met mensen ouwehoeren brengen de boodschap in mijn ervaring een stuk beter over dan managers die alleen maar in mededelingen communiceren en misschien wel zeggen dat hun deur open staat maar niet doorhebben dat de deur van hun medewerkers ook open staat. Communiceren is een werkwoord, je moet het doen. En het is tweerichtingverkeer, de boodschap die overkomt is wat de ander ervan maakt en dat weet je pas als je luistert naar wat de ander ervan gemaakt heeft.

Lees het boek "Zero Trust Networks" eens.
http://shop.oreilly.com/product/0636920052265.do

Eerder een minderheid, praktijkervaring. Het maakt heel erg uit vanuit welke kant die ervaring opgedaan is.
De OS nerd beheerder, dba dbms nerd steekt er heel anders in dan als je wat vanuit analytics bi accounting boekhouding voor elkaar probeert te krijgen. Wat antwoorden zitten bij andere posts.

Kijk eens kritisch naar waarom de vraag naar admin rechten root rechten gesteld word. Dat is waar ik naar wijs.
Door de boodschapper als schuldig bij een niet fraaie situatie te maken geef je gewoon aan waar die communicatie tussen de vraag en wat geleverd wordt faalt. Dank je dat je daarmee je ongelijk aangeeft dat de meesten wel zouden wiillen samenwerken. Het is dezelfde reden waarom de top bij bedrijven zo dol is op uitbesteding en cloud. Ze zijn de ICT liever kwijt met al die lastige personen en onbegrijpelijke problemen.


Neem nu als voorbeeld van hierboven een andere anoniem "Laat je ontwikkelaars dan met hun geroote laptops lekker in een (OTA)ontwikkel, test, acceptatie omgeving rondrommelen. Scheid deze van je (P)productie."
Atlassian (onderlinge afstemming), mail, internet , HR met de declaraties en loon, Facility Management (huisvesting) het is zeker geen productie. Je moet dat onbereikbaar maken voor de developers en testers.
Netwerkscheiding moet je niet naar die omgevingen ontwikkel test productie doen maar naar de soort toepassing, fabriek - operatie boekhouding, bi - management advies etc. Daarbinnen kun je nog verder segmenteren als de noodzaak er is.

Met boekhouding en management advies kom je niet weg met te zeggen dat je maar wat gegevens moet verzinnen (testdata) om daar de werkelijkheid hoe het loopt uit op te maken. Het zijn de productiegegevens welke bij de ontwikkelaars nodig zijn. Zie daar het conflict wat ontstaat met degenen die roepen dat zoiets niet zou mogen.

De uitweg in die hoek is machines met admin rechten zodat de lastpakken van ICT buiten de deur zijn.
Vervolgens komen er externe leveranciers bij deze groep die hun producten verkopen en die admin rechten als hun oplossing zien voor de verkoop. Als jij dit niet waarneemt of waargenomen hebt dan heb je een heel uitzonderlijk iets.

De ander tak met marketing en business analysten is dat die buiten de ICT zelf de voor nieuwe paketten met installaties gaan juist omdat ICT geen thuis geeft. Bekend als "shadow ICT". Je moet niet gek staan te kijken als meer dan de helft van het ICT gebeuren "shadow ICT" is.
Als jij dat niet waarneemt ben ik benieuwd naar je werkplek.

https://itexecutive.nl/business/kloof-it-business-digitale-agenda/ zelfde onderzoek
https://dutchitchannel.nl/631541/kloof-tussen-it-en-business-over-aanpak-digitale-agenda.html

Beste karma4, ik heb het ook over praktijkervaring. Zo'n 25 jaar aan praktijkervaring in IT-omgevingen, en de nodige in andere omgevingen. Wuif dat niet te makkelijk weg omdat het niet strookt met jouw ervaring. Misschien ben jij hier wel degene die nog iets op kan steken.

Ik heb meer dan eens meegemaakt dat twee mensen met wie ik heel behoorlijk kon samenwerken dat niet met elkaar konden. Over en weer hadden ze de ervaring dat de ander zich onredelijk gedroeg en die gingen ze dus bij voorbaat met dezelfde onredelijkheid tegemoet treden. Resultaat: ze bleven van elkaar die onredelijkheid meemaken en zagen hun oordeel alleen maar bevestigd.

Alleen zag ik als derde die met beiden kon samenwerken dat ze geen van beide onredelijk waren. Ze zagen het alleen niet van elkaar. Zie je hoe die dynamiek voor blijvende problemen kan zorgen? En hoe simpel de basis is van waaruit je dat kan doorbreken (wat minder simpel is dan die basis als er al een hoop ergernis is opgebouwd, maar niet onmogelijk)?

Ik heb ook meer dan eens meegemaakt dat ik, toen ik dit soort dingen eenmaal doorhad, prima bleek te kunnen samenwerken met mensen die de reputatie hadden onmogelijk te zijn. Ook moeilijke mensen kunnen blijken mee te vallen als je ze maar een reden geeft om coöperatief te zijn, en waar ze op reageren is coöperatief gedrag dat je zelf vertoont.

Ik heb het trouwens over de samen-tegen-as in de roos van Leary. Mijn ervaring is dat die goed klopt.

Dus nogmaals: als jij consequent meemaakt, in verschillende organisaties en contexten, dat mensen weerbarstig zijn, dan denk ik dat de kans groot is dat je dat meemaakt omdat je het zelf oproept. De kans dat je zelf het probleem bent is aanzienlijk groter dan de kans dat al die anderen stuk voor stuk het probleem zijn en er aan jouw kant niets aan schort. Ik zou in jouw plaats serieus rekening houden met de mogelijkheid dat je zoveel weerbarstigheid meemaakt omdat je je eigen weerbarstigheid van anderen terugkrijgt. Dat zou volkomen consistent zijn met de slechte ervaringen die jij met anderen hebt.

Er bestaan project- en andere managers die doorhebben dat je deadlines makkelijker haalt met gemotiveerde dan met gedemotiveerde mensen, en die doorhebben wat nodig is om motivatie levend te houden.

Nee, dat zeg ik helemaal niet. Ik heb het over de manier waarop je communiceert, niet over de essentie van de boodschap. Als jij een boodschap zo brengt dat je mensen afbrandt op bijvoorbeeld het bestaan van shadow-ict, ze bijvoorbeeld impliciet of expliciet incompetentie of tegenwerking verwijt, dan is voorspelbaar dat je van die mensen geen reactie krijgt die tot oplossingen gaan leiden. Als mensen zich aangevallen voelen schieten ze in de verdediging en komt je punt niet meer over. Als jij in plaats van allerlei foute motieven te veronderstellen uitgaat van welwillende mensen die door ongelukkige keuzes uit het verleden nu op een verkeerd spoor zitten, dan is vanuit die houding veel beter met die mensen te praten en kom je aanzienlijk verder. Ik weet natuurlijk niet of dit een juiste beschrijving is van hoe jij je op je werk gedraagt, daar ben ik niet bij, daarom heb ik het over als jij een boodschap zo brengt, niet dat je dat doet. Wat ik wel denk is dat een consequent negatieve ervaring met vele anderen een indicatie is dat er inderdaad wat aan je eigen manier van communiceren schort.

Bij een onderwerp als shadow-ict is het natuurlijk goed mogelijk dat je management boven je hebt zitten dat het bestaan van het probleem kent maar nu andere prioriteiten stelt, en het is goed mogelijk dat je het daar hartgrondig mee oneens bent. Dat is onvermijdelijk in organisaties, verschillende mensen hebben vanuit verschillende posities, achtergronden en persoonlijkheden nou eenmaal verschillende perspectieven. Ik heb in dat soort situaties zowel meegemaakt dat ik achteraf gezien volledig gelijk had maar ook dat situaties opgelost bleken te kunnen worden op manieren die ik niet had weten te bedenken. Ik moet de eerste mens nog tegenkomen die altijd gelijk heeft, en als je even nadenkt kan je bedenken dat mensen ook helemaal niet de capaciteit hebben om werkelijk alles goed te overzien. En als je erkent dat je zelf ook een mens bent en zelf die beperkingen hebt, dan is de consequentie dat je onmogelijk altijd overal gelijk in kan hebben. Dan kan volgens mij de conclusie alleen maar zijn dat de inschattingen en stellingnames van anderen relevant zijn en serieus genomen moeten worden.

Terug naar waar ik mee bezig was. Wat ik doe is je erop wijzen dat de meeste mensen van nature een stuk coöperatiever zijn dan jij lijkt mee te maken en dat er een mechanisme bestaat in menselijke interacties dat gebrek aan samenwerking in stand kan houden, en ik wijs je erop dat als jij dat steeds maar meemaakt je daar zelf wel eens een factor in kan zijn.

Een voorbeeld van negativiteit oproepen dat je regelmatig op deze site tentoonspreidt is om consequent iedereen die privacy een hoge prioriteit geeft als verdediger van criminelen neer te zetten. Jij stelt je op alsof je de motieven van een ander wel even in kan vullen en dat beter weet dan ze het zelf weten, en dat blijf je vervolgens stug volhouden als iemand je erop wijst dat het toch echt wat genuanceerder ligt, waarbij je die nuance volledig negeert. In termen van de roos van Leary vertoon jij op zo'n moment overduidelijk tegen-gedrag en roep je al even overduidelijk tegen-gedrag bij anderen op. En dat tegen-gedrag van anderen lijkt je dan weer als bevestiging te zien van het punt dat je maakt. Het punt dat ik maak is dat dat vaak niet klopt en meer aan de dynamiek van je interacties ligt met die mensen dan aan aan die mensen op zich, en dat je zoiets doorbreekt door zelf de moeite te doen daar een positievere benadering voor in de plaats te zetten.

Misschien ben je een mispunt dat het doelbewust doet, een trol dus. Dan ben ik blij dat ik niet in dezelfde organisatie werk als jij want dan ben je zelf een rat die er hard aan werkt de cultuur te verzieken. Misschien heb je werkelijk niet door dat je dat doet, bijvoorbeeld omdat je op de een of andere manier niet in staat bent tot je door te laten dringen, als een ander zegt dat iets anders ligt dan jij vindt, dat het mogelijk is dat jij ongelijk hebt en die ander gelijk heeft.

Daarom wijs ik je erop dat het effect bestaat en doe ik je de aanbeveling om eens kritisch naar je eigen aandeel in de dynamiek te kijken. Verbeter de wereld, begin bij jezelf. Ken je die uitdrukking? Die bevat een hoop wijsheid.

Ah ik heb je kennelijk geraakt als projectmanager. Daar heb ik goed en slechte van meegemaakt.
De kritiek die ik lever gaat over de slechte gevallen, kennelijk voel je je daar aangesproken.
Als je ontkent dat er veel projecten mislukken dan is er iets grondig bij je mis.
https://www.lrgd.nl/Portals/1/Symp_2016_materiaal/2016-E2-6-Waarom%20grote%20ICT-projecten%20vaak%20mislukken%20mei%202013%20Informatie%20p42-49.pdf
Voor managers moet deze gesneden kost zijn: https://www.slideshare.net/apanitsch/the-management-rowing-race
De beroemde swing tree is net zo'n klassieker. Nee wat ik waarneem is dat jij kennelijk vast in je geloof dat de projectmanager alleswetend en onfeilbaar is. Met het agile manifesto is dat een geheel andere kant uitgegaan https://agilemanifesto.org/
War je kennelijk problemen mee hebt is kritiek over zaken die niet goed lopen. Het is een bekend fenomeen dat iedereen zijn mond houdt totdat de schade onherstelbaar is. Ik zoek even en dit is de eerst hit.
https://www.managementsite.nl/bureau-ict-toetsing-kritisch

Ik brand mensen niet af zeker de TS van deze draad hier niet. Ik heb enkel de analyse gedaan dat de oorzaak en reden van de vraag in het shadow ICT gebeuren met de bekende mismatch ICT en organisatie kan liggen.

Mensen kunnen coöperatiever als de tijd en het budget en het moment juist is. Daar heb ik vaak genoeg gebruik van gemaakt. Dan nog heb je te maken met andere agenda's en doelen welke kunnen spelen. Een PL hoort dat te beseffen.
Ik ben echt niet de enige die dat ziet. Het stond al in het SDM-2 (voorloper prince en andere projectmethodieken).
https://www.compact.nl/articles/gedrag-kritische-factor-voor-succesvolle-ict-projecten/
"Alle betrokken projectmedewerkers wisten dat hun statusrapportage een getrouw beeld gaf maar dat het finale rapport niet klopte. Toch werd niet geëscaleerd. Waarom niet?"
Met enkel ja knikkers die daarnaast het gewenste resultaat niet kunnen leveren zit de PL wel lang op het project. De faal ligt voor de hand. Als dat de door jouw uit te dragen gewenste methode is, dan zijn we het duidelijk niet eens.

Ik ben juist heel erg voor privacy, echter wat je ziet gebeuren is een doorgeslagen insteek welke privacy schendend werkt.
Als dat je werkelijke probleem is, dan moet je dat uitspreken en daarover iets aparts starten.

Ik heb last van het soort ratten zoals in de betreffende handleiding. Het is nogal kortzichtig om aan te nemen dat dat soort figuren niet bestaan. Gelukkig zijn ze in de minderheid maar daarmee zijn ze niet minder ernstig storend en beschadigend.

Ik weet niet aan welke cultuur jij nu zelf werkt, ik zie er weinig opbouwends of constructiefs in. De nuances ontbreken.
In een onderwerp met admin rechten op desktops presteer je het om een persoonlijke aanval in te zetten.

Je laatste advies om de wereld te verbeteren en bij je zelf te beginnen is een heel goede.
Kennelijk heb je last van wat onverwerkte pijnpunten in projectmanagement mogelijk wat techniek en wat rond het privacy gebeuren.

Welnee, ik ben nooit projectmanager geweest.

De rest van je reactie bevestigt dat je het punt wat gemaakt wordt niet tot je door laat dringen maar er iets compleet anders van maakt. Ik ga niet herhalen wat ik al geschreven heb.

Als je dan de rol van projectmanager nooit vervuld hebt maar wel met dat beeld een ander de maat wil nemen bevestigd dat waar ik op aan stuurde. Je bent bezig op een andere negatieve manier proberen je gelijk te halen in een ad hominem wijze.

Waar is je positieve inbreng voor het onderwerp van topic starter?
Wat is je positieve inbreng om foute situaties te willen verbeteren?
Inderdaad is je aanpak een van de wijzen waarop de negatieve stoorzenders saboteurs werken. Het beeld naar buiten dat ze met alles het beste voor hebben en dat iedereen heel goed naar ze luistert wegens dat positieve. Een naslagwerkje voor je: https://www.managementboek.nl/boek/9789055945535/de-projectsaboteur-jeroen-gietema

Degenen die met gegronde kritiek komen dat zijn nu juiste degenen waar je wat aan hebt om de echte problemen op tijd voor te zijn. Het achteraf gelijk komt voor met klokkenluiders als de foute situatie heel erg fout gaat.

Ik ben ervoor om zelfs niet dev's admin rechten te geven in hun eigen werkplek/omgeving/purism phone/laptop

Zorg voor.goede backup (full disk)... dat is het wel een beetje.

Op hun device gewoon eigen account, ander wachtwoord dan ze op local network en vpn hebben natuurlijk!

Een 'naslagwerkje'? De samenvatting en omschrijving lezen als die van zelfhulpboeken, met open deuren en vaagheden, waar je eigenlijk niets aan hebt maar waarmee iemand wel veel geld verdient. Zoiets kan je toch niet vergelijken met professionele vakliteratuur!

Zoiets zou natuurlijk wel leesvoer zijn voor zo'n wannabe aan de zijlijn. Zo eentje die zó graag mee zou willen doen maar nooit de kans heeft gekregen. Zo iemand die het altijd 'beter' weet dan de echte experts.

Jammer dan dat je zelf niet open staat voor misschien wel gegronde kritiek als die je eigen manier van doen betreft. Je kan dat afdoen als "ad hominem" maar je zou je ook kunnen afvragen of er misschien wat zit in het vermoeden dat als jij zo vaak als je hier doet voorkomen met negativiteit te maken hebt het wel eens een reactie op je eigen manier van doen kan zijn.

Ik reageer hier op de negativiteit met een negativiteit.
Misschien begrijp je wat actie - reactie en je eigen verwijzing betekent. Er is weinig positiviteit in de gangbare reacties.
Nee ik ga je niet de lange lijst van positive ervaringen vertellen
Er is kennelijk nog geen behoefte aan.

Blijft nog steeds dat de foute negatieve zaken de meeste aandacht krijgen. Je hoeft er enkel voor naar een krant te kijken. Iets wat goed gaat daar kan je op bezuinigen wat fout gaat daar kan je mee scoren.

Door ze er van te doordringen enkel sudo te gebruiken wanneer dat inhoudelijk nodig is, en niet altijd als root te willen werken ? Kwestie van awareness ?

Misschien zou je daar eens mee moeten ophouden, want daar je zelf mede debet aan. Denk je nu echt dat al jouw gemopper en betweterij Nederland ook maar iets bestendiger tegen een ontwrichting heeft gemaak? Ik dacht het niet.


Ja, het is nog een hele kunst om goed gemutst te blijven...

Lees eens The Art of Thinking Clearly (2013) van Rolf Dobelli, dat is ook in het Nederlands vertaald. Neem vooral de raad in Hoofdstuk 99 van dat boek ter harte. Veel nieuws lezen is ongezond, dus daar zou ik maar eens mee stoppen.

Nogmaals ik reageer op de negativiteit. Ook jij schijnt het negativisme niet te kunnen laten.
Als je positiviteit wilt moet je dat tonen. Goed gemutst kunnen zijn betekent dat je ook andere meningen erkent.

En nogmaals het is niet het zelfde als ja knikkers zien te verzamelen.
Dat soort figuren die ja knikkers wensen, dat zijn nu net niet de positivisten. Ze brengen het beeld van positief zijn het tegendeel is er aan de hand.

https://deanyeong.com/reading-note/the-art-of-thinking-clearly/
Dacht je dat ik de hele lijst als niet vaker heb zien passeren? Ik ben altijd wat verrast dat degenen die er mee komen vaak zelf de grootste problemen er mee hebben.

Nog steeds de vraag:
- wat heb je voor positiefs als advies voor TS?

Begrijp ik nu goed dat jouw positie is dat jij op negativiteit zal reageren met negativiteit en dat het aan de ander is om dat met positiviteit te doorbreken omdat jij dat niet zal doen? Dat zou om twee redenen een problematische houding zijn.

De eerste reden is dat niemand ooit over de brug zal komen als iedereen het standpunt inneemt dat een ander dat als eerste zal moeten doen. Wil er iets verbeteren dan zal iemand de eerste moeten zijn en dan zal dus iemand bereid moeten zijn om niet met negativiteit op negativiteit te reageren. Iedereen die dat verdomt helpt de negativiteit in stand te houden.

De tweede reden is dat je heel makkelijk in die situatie belandt als je bij de ander negativiteit ziet terwijl de ander dat helemaal niet zo bedoelt. Een slordige formulering, een simpele interpretatiefout of verkeerde inschatting van iemands motieven kan dan betekenen dat de iemand negatief reageert, waarop de ander weer negatief reageert, en daar ga je.

Je lijkt het bewust toe te passen door bewust met negativiteit op negativiteit te reageren. Het hele punt is dat als je dat snapt je dat inzicht kan gebruiken om het te doorbreken: reageer eens niet met negativiteit op negativiteit.

Inderdaad.

Gladde manipulators zijn er ook, ja, en daar kan je verdomd veel last van hebben. De meeste mensen voldoen gelukkig niet aan die omschrijving.

Ik heb op 08-10-2019, 11:50 de vraagsteller aangeraden de man page te bestuderen, ook al is die vrij taai. Die geeft namelijk inzicht in wat er allemaal met sudo mogelijk is en dat inzicht stelt de vraagsteller hopelijk in staat het in zijn situatie goed in te zetten. Dat is een positief advies omdat het hem verder kan helpen.

Welk positief advies heb je zelf trouwens voor de vraagsteller? Jouw eerste reactie op deze pagina, 08-10-2019, 16:39, ging over wat er in jouw ogen allemaal fout zit, maar geen enkel advies over hoe je dat dan beter kan doen.

Voor de duidelijkheid: de reactie van gisteren, 19:40 door Anoniem was niet van mij.

@ Anoniem van gisteren 19:40: het is wel zo duidelijk als je "Andere Anoniem hier" of zo'n soort opmerking plaatst om misverstanden te voorkomen.

Mij positieve advies is wat aan de oorzaken van iets ongewenst te gaan doen.

Je kunt proberen te dweilen met de kraan open. Het is beter om de kraan dicht te krijgen dan de beste dweil zien te vinden.

Prima, genoeg gezegd.

Het zou daarbij natuurlijk wel helpen als dat 'iets ongewenst' geen off-topic geraaskal zou zijn, wat alleen tussen jouw oren realiteit lijkt te hebben.

Soms zie je door de anoniemen de anoniem niet meer ;-/ Als men geen account wil aanmaken dan is het misschien een idee om een signature onder het bericht te zetten? Zoals bv. luntrus dat doet.

Van nieuwe anoniemen verwachten dat ze controleren of er al andere anoniemen hebben gepost is ondoenlijk. Mede omdat de berichten van anoniemen vertraagd (i.v.m. moderatie) binnenkomen.

Klinkt als: Verkeerde brandstof tanken en schade beperken.

Wat luntrus en #sockpuppet doen, als "Anoniem" toch met een signatuur afsluiten, dat moeten ze zelf weten, maar dat zou ik niet doen als ik jou was. Dat is niet verstandig, want iedereen kan zo'n willekeurige ondertekening plaatsen.

Impersonatie heb ik zelf al meemaakt op dit forum hier. Met quotes die ik elders heb gebruikt. Ooit op IRC 5 jaar geleden. Daar ben ik al jaren vanaf want daar ging het verder (impersonation).

Ik kijk nauwelijks nog op deze site. Als ik ooit terug komt dan registreer ik een vaste naam en zorg ik goed voor het wachtwoord. Mijn verbinding kan ook nog wat security gebruiken... Ik sluit me helemaal aan bij uw commentaar. Er zijn mensen actief in onze maatschappij en die vinden je ook op online fora wiens bezigheid is het doxen van mensen, foppen, en smaadt en laster dat zit er ook nog bij.

Men is beter af met een publiek profiel dan helemaal anoniem met kopieerbare quotes die oneindig gecloned kunnen worden. Mijn doxers gebruiken een soort zoekmachine en zijn bedreven in taalpatronen (ML/ AI) als je genoeg schrijfsels van een persoon hebt dan kun je er een Machine Learning profiel van laten maken om de persoon op te sporen online of deze te clonen voor oplichterij of andere ongure zaken.

[OFF TOPIC] (maar deze draad had, zoals helaas zovele, al vele "bijdragen" niets meer met de vraag van de TS te maken).

In https://www.security.nl/posting/628112/crypto+bewijs%3A+dezelfde+anoniem laat ik zien hoe een anoniem kan bewijzen dat hij/zij dezelfde anonieme auteur is als van een eerdere bijdrage. Maar of anoniemen dit algoritme daadwerkelijk gaan gebruiken, moet ik nog zien ;-)

[/OFF TOPIC]

[OFF TOPIC]
Dat zal nogal een hoge drempel zijn vrees ik ook. Maar nu we toch in technische oplossingen aan het denken zijn. Voor security.nl zou het een kleine moeite zijn om met de on-line fingerprint v.e. gebruiker (ip-adres, browser id, os, patronen in muis- en toetsenbordgebruik, etc.) een uniek token te genereren en die bij elk bericht van een als anoniem postende gebruiker te plaatsen. Ja maar dat is privacygevoelige informatie? Mwah... (in principe niet herleidbaar naar gebruiker want die is immers al anoniem.
[/OFF TOPIC]

@Superuser: ivm de "topicness" schrijf ik zo iets over fingerprinting in de thread "crypto bewijs: dezelfde anoniem".

Er kan ook een gesproken code wordt verstuurd naar een ("vaste") telefoon, maar sms werkt het snelste, ook al is het op zichzelf niet veilig. Je moet immers ook nog de gewone inlogcode en wachtwoord hebben.

Je moet het kind niet met het badwater weggooien.