3 manieren waarop ontwikkelaars zonder code zichzelf in de voet kunnen schieten PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.

3 manieren waarop no-code-ontwikkelaars zichzelf in de voet kunnen schieten

Er was een tijd dat risicomijdende organisaties het vermogen van hun zakelijke gebruikers om kostbare fouten te maken ernstig konden beperken. Met beperkte technische kennis, strikte machtigingen en gebrek aan wind in de rug, was het ergste wat een zakelijke gebruiker kon doen, malware downloaden of in een phishing-campagne trappen. Die dagen zijn nu voorbij.

Tegenwoordig, elk groot software-as-a-service (SaaS)-platform wordt gebundeld geleverd met mogelijkheden voor automatisering en het bouwen van applicaties die zijn ontworpen voor en rechtstreeks op de markt worden gebracht voor zakelijke gebruikers. SaaS-platforms zoals Microsoft 365, Salesforce en ServiceNow zijn aan het inbedden no-code/low-code platformen in hun bestaande aanbod, waardoor ze rechtstreeks in de handen van zakelijke gebruikers worden geplaatst zonder om goedkeuring van het bedrijf te vragen. Mogelijkheden die ooit alleen beschikbaar waren voor de IT- en ontwikkelingsteams, zijn nu beschikbaar in de hele organisatie.

Power Platform, het low-code platform van Microsoft, is ingebouwd in Office 365 en is een goed voorbeeld vanwege de sterke positie van Microsoft in de onderneming en de snelheid waarmee het door zakelijke gebruikers wordt overgenomen. Misschien zonder het te beseffen, leggen ondernemingen de macht op ontwikkelaarsniveau in handen van meer mensen dan ooit tevoren, met veel minder beveiliging of technische kennis. Wat zou er mis kunnen gaan?

Eigenlijk best veel. Laten we een paar praktijkvoorbeelden uit mijn ervaring bekijken. De informatie is geanonimiseerd en bedrijfsspecifieke processen zijn weggelaten.

Situatie 1: Nieuwe leverancier? Doe het gewoon

Het klantenserviceteam van een multinationaal retailbedrijf wilde hun klantgegevens verrijken met consumenteninzichten. Ze hoopten met name meer informatie te vinden over nieuwe klanten, zodat ze hen beter van dienst konden zijn, zelfs tijdens hun eerste aankoop. Het klantenserviceteam heeft een leverancier gekozen waarmee ze willen samenwerken. De leverancier eiste dat er gegevens naar hen werden verzonden voor verrijking, die vervolgens door hun diensten zouden worden teruggetrokken.

Normaal gesproken komt IT hier in beeld. IT zou een soort integratie moeten bouwen om gegevens van en naar de leverancier te krijgen. Het IT-beveiligingsteam moet uiteraard ook worden betrokken om ervoor te zorgen dat deze leverancier kan worden vertrouwd met klantgegevens en de aankoop kan goedkeuren. Inkoop en juridische zaken zouden ook een sleutelrol hebben gespeeld. In dit geval ging het echter een andere kant op.

Dit specifieke klantenserviceteam bestond uit Microsoft Power Platform-experts. In plaats van te wachten op bronnen of goedkeuring, gingen ze gewoon door en bouwden ze de integratie zelf: klantgegevens verzamelen van SQL-servers in productie, alles doorsturen naar een FTP-server van de leverancier en verrijkte gegevens terughalen van de FTP-server naar de productiedatabase. Het hele proces werd automatisch uitgevoerd telkens wanneer een nieuwe klant aan de database werd toegevoegd. Dit gebeurde allemaal via drag-and-drop-interfaces, gehost op Office 365 en met behulp van hun persoonlijke accounts. De licentie werd uit eigen zak betaald, waardoor inkoop buiten de lus bleef.

Stel je de verbazing van de CISO voor toen ze een aantal bedrijfsautomatiseringen ontdekten die klantgegevens naar een hardgecodeerd IP-adres op AWS verplaatsten. Als een klant die alleen Azure is, veroorzaakte dit een gigantische rode vlag. Bovendien werden de gegevens verzonden en ontvangen met een onveilige FTP-verbinding, waardoor er een veiligheids- en compliancerisico ontstond. Toen het beveiligingsteam dit ontdekte via een speciale beveiligingstool, waren er al bijna een jaar gegevens in en uit de organisatie gegaan.

Situatie 2: Ohh, is het verkeerd om creditcards te verzamelen?

Het HR-team van een grote IT-leverancier bereidde zich voor op een jaarlijkse "Give Away"-campagne, waarbij werknemers worden aangemoedigd om te doneren aan hun favoriete goede doel, waarbij het bedrijf meedoet door elke door werknemers gedoneerde dollar te verdubbelen. De campagne van vorig jaar was een enorm succes, dus de verwachtingen waren torenhoog. Om de campagne kracht bij te zetten en handmatige processen te verlichten, gebruikte een creatieve HR-medewerker het Power Platform van Microsoft om een ​​app te maken die het hele proces faciliteerde. Om zich te registreren, logt een medewerker in op de applicatie met zijn bedrijfsaccount, voert zijn donatiebedrag in, selecteert een goed doel en verstrekt zijn creditcardgegevens voor betaling.

De campagne was een groot succes, met een recordparticipatie van medewerkers en weinig handmatig werk van HR-medewerkers. Om de een of andere reden was het beveiligingsteam echter niet blij met de gang van zaken. Tijdens het registreren voor de campagne realiseerde een medewerker van het beveiligingsteam zich dat creditcards werden verzameld in een app die er niet naar uitzag dat dit zou moeten. Na onderzoek ontdekten ze dat er inderdaad niet goed met die creditcardgegevens was omgegaan. Creditcardgegevens werden opgeslagen in de standaard Power Platform-omgeving, wat betekent dat ze beschikbaar waren voor de gehele Azure AD-tenant, inclusief alle werknemers, leveranciers en aannemers. Bovendien werden ze opgeslagen als eenvoudige tekenreeksvelden in leesbare tekst.

Gelukkig werd de schending van de gegevensverwerking ontdekt door het beveiligingsteam voordat kwaadwillende actoren - of compliance-auditors - het opmerkten. De database is opgeschoond en de applicatie is gepatcht om financiële informatie correct te verwerken volgens de regelgeving.

Situatie 3: Waarom kan ik Gmail niet gewoon gebruiken?

Als gebruiker houdt niemand van maatregelen om gegevensverlies te voorkomen. Zelfs wanneer dat nodig is, zorgen ze voor hinderlijke frictie in de dagelijkse gang van zaken. Als gevolg hiervan hebben gebruikers altijd geprobeerd ze te omzeilen. Een eeuwigdurend touwtrekken tussen creatieve zakelijke gebruikers en het beveiligingsteam is zakelijke e-mail. Zakelijke e-mail synchroniseren met een persoonlijk e-mailaccount of zakelijke agenda met een persoonlijke agenda: beveiligingsteams hebben daar een oplossing voor. Ze hebben namelijk e-mailbeveiliging en DLP-oplossingen geïmplementeerd om het doorsturen van e-mail te blokkeren en gegevensbeheer te waarborgen. Dit lost het probleem op, toch?

Welnee. Een herhaalde bevinding in grote ondernemingen en kleine bedrijven ontdekt dat gebruikers automatiseringen creëren die e-mailcontroles omzeilen om hun zakelijke e-mail en agenda door te sturen naar hun persoonlijke accounts. In plaats van e-mails door te sturen, kopiëren en plakken ze gegevens van de ene service naar de andere. Door met een aparte identiteit in te loggen op elke service en het kopieer- en plakproces te automatiseren zonder code, omzeilen zakelijke gebruikers met gemak beveiligingscontroles - en zonder gemakkelijke manier voor beveiligingsteams om erachter te komen.

De Power Platform-community heeft zich zelfs ontwikkeld templates die elke Office 365-gebruiker kan oppikken en gebruiken.

Met grote kracht komt grote verantwoordelijkheid

De empowerment van zakelijke gebruikers is geweldig. Bedrijfsonderdelen moeten niet wachten op IT of vechten om ontwikkelingshulpmiddelen. We kunnen echter niet zomaar zakelijke gebruikers macht op ontwikkelaarsniveau geven zonder begeleiding of vangrails en verwachten dat alles goed komt.

Beveiligingsteams moeten zakelijke gebruikers opleiden en hen bewust maken van hun nieuwe verantwoordelijkheden als applicatieontwikkelaars, zelfs als die applicaties zijn gebouwd met "geen code". Beveiligingsteams moeten ook vangrails en monitoring plaatsen om ervoor te zorgen dat wanneer zakelijke gebruikers een fout maken, zoals wij allemaal doen, dit niet zal uitmonden in complete datalekken of compliance-auditincidenten.

Tijdstempel:

Meer van Donkere lezing