Leverancier wil remote toegang. Wat is gebruikelijk?

[wizl]

Ons bedrijf levert software. Die software gebruikt als DBMS Microsoft SQL Server. Tot nu toe stellen al onze klanten ons in staat deze server van op afstand te benaderen. De ene klant is daarin wat makkelijker dan de ander. Er zijn servers rechtstreeks via RDP benaderbaar over internet (soms met ons bron-ip als 'beveiliging'). Voor andere klanten maak ik een VPN waar ik voor het wachtwoord eerst moet bellen om een (RSA)cipher te vragen.
Weer anderen zijn ontsloten met LogMeIn IT-Reach. En zo zijn er nog 20 smaken

Nu tref ik een klant die er ABSOLUUT niet aan wil. Elke vorm van toegang tot zijn netwerk is per definitie onbespreekbaar

Mijn vraag aan jullie. Wat is gebruikelijk? Ik ga er vanuit dat zelfs leveranciers bij de overheid, banken, advocatenkantoren, multinationals etc. op een of andere manier toegang krijgen. Dat is anno 2009 toch niet zo heel veel gevraagd?

En wat zijn dan de manieren waarop jullie toegang krijgen, of juist één en ander dichtgetimmerd hebben?

[DiedX]

Bij ons had je ook geen toegang gekregen. Punt. Nu zitten we wel in de informatiebeveiliging, dus dat is niet ongangbaar in die wereld. Wat voor klant is het?

[Cubix]

Simpel, wanneer ze geen toegang verlenen moet er een mannetje van jullie bedrijf op locatie verschijnen. Duurder voor de klant en minder snel. Aan de klant de keuze.

Ik begrijp zeker dat sommige bedrijven geen toegang van buiten op hun netwerk tolereren.

[Verwijderd]

Ervaring vanuit een CMS bedrijf waar ik gewerkt heb voor de overheid had hetzelfde.

We hadden systemen op locatie staan bij verschillende overheidsklanten door heel nederland heen. Sommige waren 3 uur reizen. Deze wilden om veiligheidsredenen geen RDP connectie of what so ever opstellen. Er moest dus iemand op locatie komen.

Wanneer je een stuk beveiliging implementeerd moet je altijd denken dat dat een stuk flexibiliteit en comfort inlevert. Zeker als je cruciale systemen hebt draaien.

In ons geval hield dat in dat we geen SLA konden aangaan waarbij we een support van binnen 24 uur konden waarmaken en dat wanneer wij op locatie moesten komen, zij opdraaide voor de reiskosten en reisuren.

[To_Tall]

Denk dat je als bedrijf zijnde gewoon geen externe op je omgeving wil hebben vanaf een externe locatie.

Security policy, kan je zo een rijtje met soort bedrijven gegeven die dat totaal nooit zouden toestaan. anagezien er teveel gevoelige informatie bloot gelegd kan worden

Gewoon bij de klant langs gaan. Kost hem dan wel voorrijkosten.

[m0nk]

Zorginstelling hier. Leveranciers bellen ons op voor een RSA token response om in te loggen. Ik laat ze dan een citrix sessie opbouwen die ik door onze servicedesk laat shadowen. In enkele gevallen weigeren wij het ook. Wij laten ze dan gewoon langs komen. Kost meer en duurt langer, maar das dan maar zo. Uiteraard heeft dat meestal wel een voorgeschiedenis. Wat betreft jullie klant, als zij er echt niet aan willen dan moet je daar genoegen mee nemen. Of dat bedrijf niet als klant aannemen.

[Verwijderd]

m0nk schreef op donderdag 12 maart 2009 @ 15:18:
Zorginstelling hier. Leveranciers bellen ons op voor een RSA token response om in te loggen. Ik laat ze dan een citrix sessie opbouwen die ik door onze servicedesk laat shadowen. In enkele gevallen weigeren wij het ook. Wij laten ze dan gewoon langs komen. Kost meer en duurt langer, maar das dan maar zo. Uiteraard heeft dat meestal wel een voorgeschiedenis. Wat betreft jullie klant, als zij er echt niet aan willen dan moet je daar genoegen mee nemen. Of dat bedrijf niet als klant aannemen.

Ow, zo'n leuke systeembeheerder die elke klik gaat zitten meekijken, en als je iets niet goeddoet een berichtje naar de gebruiker stuurt met 'NEEM METEEN CONTACT OP MET BLABLA (tel [phone])' .. 2 keer gehad met klant. Ff snel een update er doorheen rammen zonder toestemming vragen is vaak niet zo handig, maar als iets hoge urgentie heeft vaak wel relevant.. Er wordt ook altijd zo heerlijk gecommuniceerd binnen 'voornamelijk' overheid'..

Verder zal een beetje grote klant met grote systemen er goed aan doen door dergelijke applicaties op aparte servers dan wel vm omgevingen neer te zetten. Zo kunnen ze een leverancier op een omgeving laten werken. In plaats van verschillende applicaties op een db laten draaien en dan een leverancier de schuld geven dat hun applicatie niet werkt omdat de andere leverancier een update gedaan aan de db waardoor gegevens verloren zijn gegaan..

[bonzz.netninja]

m0nk schreef op donderdag 12 maart 2009 @ 15:18:
Zorginstelling hier. Leveranciers bellen ons op voor een RSA token response om in te loggen. Ik laat ze dan een citrix sessie opbouwen die ik door onze servicedesk laat shadowen. In enkele gevallen weigeren wij het ook. Wij laten ze dan gewoon langs komen. Kost meer en duurt langer, maar das dan maar zo. Uiteraard heeft dat meestal wel een voorgeschiedenis. Wat betreft jullie klant, als zij er echt niet aan willen dan moet je daar genoegen mee nemen. Of dat bedrijf niet als klant aannemen.

leverancier hier Wij krijgen meestal ook toegang zoals de TS bespreekt. Als een klant dat weigert gaan we inderdaad langs, maar kost het nogal wat tijd. Nu scheelt het dat wij internet applicaties leveren dus veel thuis hosten maar soms moeten we koppelen met interne systemen e.d

Ik quote m0nk omdat wij ook wel eens zaken doen met een zorginstelling (een zeker ziekenhuis in noordholland) en daar moeten wij idd eerst sochtends een token aanvragen. Een best goede oplossing, alhoewel het voor ontwikkeling een beetje gedoe is. Nu moet mijn ontwikkelaar elke ochtend ff bellen. Maar goed, het is een kleine moeite (en kost uiteraard gewoon even tijd)

Wat we ook wel doen is een test server ergens ertussen waarop we deployen om te testen en vervolgens de packages gewoon aan de klant ict beheerder geven. Dan mag hij het zelf doen. Als je beetje van deze tijd bent zorg je ook dat het sowieso deployable packages zijn met wat logging en terugdraai mogelijkheden. Bij sharepoint aanpassingen hoeven we bijvoorbeeld nooit meer live toegang te hebben maar zorgen we dat we iets deploybaars hebben en een testomgeving die gelijk is aan live.

[ Voor 16% gewijzigd door bonzz.netninja op 12-03-2009 15:38 ]

[m0nk]

Tja, in het verleden te vaak meegemaakt dat een leverancier toch even die extra update installeert waardoor er een belangrijke koppeling niet meer werkt of half werkt waardoor er een half crisisteam naar binnen wordt gehaald om de problemen op te lossen omdat er een aantal mutaties in ons zorgregistratie systeem niet good doorkomen in het planning systeem.

Hier worden dus vanaf die periode duidelijk afspraken gemaakt met welke werkzaamheden een leverancier uitvoert. Onze servicedesk heeft de shadow schermen dus ook altijd open en kijken zo nu en dan mee wat er gebeurd. Sindsdien hebben onze leveranciers niks anders meer gedaan dan afgesproken. Misschien irritant voor de leverancier, maar ik word niet meer uit bed gebeld omdat er "op en eens" iets niet meer werkt en dat dan blijkt dat er toch meer uitgevoerd heeft dan afgesproken en getest. Wat betreft ontwikkeling, ik geef ze meestal gewoon toegang (wel dmg gpo's en ad rechten) tot de OTA omgevingen. Productieomgevingen is zonder afspraak en klein beetje toezicht een no go.

[Verwijderd]

bonzz.netninja schreef op donderdag 12 maart 2009 @ 15:35:
[...]

leverancier hier Wij krijgen meestal ook toegang zoals de TS bespreekt. Als een klant dat weigert gaan we inderdaad langs, maar kost het nogal wat tijd. Nu scheelt het dat wij internet applicaties leveren dus veel thuis hosten maar soms moeten we koppelen met interne systemen e.d

Ik quote m0nk omdat wij ook wel eens zaken doen met een zorginstelling (een zeker ziekenhuis in noordholland) en daar moeten wij idd eerst sochtends een token aanvragen. Een best goede oplossing, alhoewel het voor ontwikkeling een beetje gedoe is. Nu moet mijn ontwikkelaar elke ochtend ff bellen. Maar goed, het is een kleine moeite (en kost uiteraard gewoon even tijd)

Wat we ook wel doen is een test server ergens ertussen waarop we deployen om te testen en vervolgens de packages gewoon aan de klant ict beheerder geven. Dan mag hij het zelf doen. Als je beetje van deze tijd bent zorg je ook dat het sowieso deployable packages zijn met wat logging en terugdraai mogelijkheden. Bij sharepoint aanpassingen hoeven we bijvoorbeeld nooit meer live toegang te hebben maar zorgen we dat we iets deploybaars hebben en een testomgeving die gelijk is aan live.

En dat gaat altijd goed.. Die systeembeheerders weten vaak veel van systeembeheer maar niet van applicatiebeheer iets af. Je zult elke keer een hoop documentatie moeten meegeven hoe ze dingen moeten instellen. Dit lijkt me niet de beste optie omdat je ook geen support op je live server kan geven..

[bonzz.netninja]

Verwijderd schreef op donderdag 12 maart 2009 @ 15:51:
[...]


En dat gaat altijd goed.. Die systeembeheerders weten vaak veel van systeembeheer maar niet van applicatiebeheer iets af. Je zult elke keer een hoop documentatie moeten meegeven hoe ze dingen moeten instellen. Dit lijkt me niet de beste optie omdat je ook geen support op je live server kan geven..

uiteraard doe je dat alleen met partijen die je genoeg instructies geeft en een beetje vertrouwd. Maar dat lijkt me tamelijk evident. En nogmaals, met goede packages en voornamelijk goede testomgevingen is het (in onze business) tamelijk fail proof. En nee, we laten het niet door de eerste beste systeembeheerder doen die de ballen geen verstand heeft van wat ze doen.

[MuddyMagical]

m0nk schreef op donderdag 12 maart 2009 @ 15:48:
Tja, in het verleden te vaak meegemaakt dat een leverancier toch even die extra update installeert waardoor er een belangrijke koppeling niet meer werkt of half werkt waardoor er een half crisisteam naar binnen wordt gehaald om de problemen op te lossen omdat er een aantal mutaties in ons zorgregistratie systeem niet good doorkomen in het planning systeem.

Hier worden dus vanaf die periode duidelijk afspraken gemaakt met welke werkzaamheden een leverancier uitvoert. Onze servicedesk heeft de shadow schermen dus ook altijd open en kijken zo nu en dan mee wat er gebeurd. Sindsdien hebben onze leveranciers niks anders meer gedaan dan afgesproken. Misschien irritant voor de leverancier, maar ik word niet meer uit bed gebeld omdat er "op en eens" iets niet meer werkt en dat dan blijkt dat er toch meer uitgevoerd heeft dan afgesproken en getest. Wat betreft ontwikkeling, ik geef ze meestal gewoon toegang (wel dmg gpo's en ad rechten) tot de OTA omgevingen. Productieomgevingen is zonder afspraak en klein beetje toezicht een no go.

Volledig mee eens. Je bent zelf toch meestal verantwoordelijk voor het feit dat het blijft draaien, dus speel je maar volgens onze regels. Hebben het hier ook gehad dat een leverancier een 'paar dingetjes' ging doen die ons daarna 2 dagen werk kostte omdat er misschien toch niet getest was of het wel kon.

Wij hebben daarom nu 1 regel: My way or the highway.

[Verwijderd]

bonzz.netninja schreef op donderdag 12 maart 2009 @ 15:55:
[...]

uiteraard doe je dat alleen met partijen die je genoeg instructies geeft en een beetje vertrouwd. Maar dat lijkt me tamelijk evident. En nogmaals, met goede packages en voornamelijk goede testomgevingen is het (in onze business) tamelijk fail proof. En nee, we laten het niet door de eerste beste systeembeheerder doen die de ballen geen verstand heeft van wat ze doen.

Schuif je dan ook de gehele verantwoordelijkheid van updaten naar hen toe wanneer het wel mis gaat? Niet dat je daarvan uitgaat en het zal ook niet snel voorkomen maar je moet wel duidelijke SLA's met de klant afspreken wie verantwoordelijk is.

[wizl]

Onze klant is voor de bedrijfsvoering afhankelijk van onze software. Als onze applicatie niet werkt staat er binnen de korste keren een flinke file ergens in het land. Verder is het een 'normaal' bedrijf. Geen bank ofzo dus.

Ik begrijp dat het in de basis een vertrouwenskwestie is. De klant moet er dus vanuit kunnen gaan dat niet zomaar updates worden geplaatst. Dat een en ander fatsoenlijk getest is etc. Als je een leverancier dan toegang geeft via een VPN beveiligd met een RSA token waarvoor je moet bellen. De SQL server dan in een DMZ voor mijn part, dat is toch gewoon harstikke veilig?!? (dus in gedachten houden dat je de leverancier moet vetrouwen voor wat betreft de acties die ze op het systeem uitvoeren)

Subvraag: Heeft er iemand ook al eens in de 'accountants'-sfeer mee te maken gehad? Dus dat die over compliance gaan zeuren omdat externe partijen toegang hebben?

[ Voor 17% gewijzigd door wizl op 12-03-2009 16:24 ]

[Verwijderd]

wizl schreef op donderdag 12 maart 2009 @ 16:21:
Onze klant is voor de bedrijfsvoering afhankelijk van onze software. Als onze applicatie niet werkt staat er binnen de korste keren een flinke file ergens in het land. Verder is het een 'normaal' bedrijf. Geen bank ofzo dus.

Ik begrijp dat het in de basis een vertrouwenskwestie is. De klant moet er dus vanuit kunnen gaan dat niet zomaar updates worden geplaatst. Dat een en ander fatsoenlijk getest is etc. Als je een leverancier dan toegang geeft via een VPN beveiligd met een RSA token waarvoor je moet bellen. De SQL server dan in een DMZ voor mijn part, dat is toch gewoon harstikke veilig?!? (dus in gedachten houden dat je de leverancier moet vetrouwen voor wat betreft de acties die ze op het systeem uitvoeren)

Subvraag: Heeft er iemand ook al eens in de 'accountants'-sfeer mee te maken gehad? Dus dat die over compliance gaan zeuren omdat externe partijen toegang hebben?

Graag willen klanten overal van op de hoogte zijn. Ze willen weten wat er met hun systemen gebeurd. Als jullie iets verkloten kan het zijn dat zij voor de financiele kosten. Een beetje jezelf beschermen is best te begrijpen.

Tuurlijk zal alles goed getest zijn en daar vertrouwen zij ook op. Anders hadden zij als klant niet voor jou gekozen als leverancier. Maar dit is gewoon dat ze hun eigen systemen in eigen handen willen houden. Daarbij is een systeem NOOIT 100% veilig, ook niet in een DMZ. Door deze mogelijkheden helemaal dicht te timmeren wordt het systeem wel iets veiliger, zeker als ik hoor dat het systeem qua availability enorm belangrijk is.

[Motrax]

Er wordt hier geredeneerd vanuit de leverancier. Dat is leuk, maar de leverancier is vaak niet alleen bij een klant. Die klant heeft misschien wel 100 externe leveranciers. Als je alle 100 toegang moet geven, heb je een reeel veiligheidsrisico.

Ik kan me goed voorstellen dat de klant alles naar buiten toe dichtspijkert, tenzij het voor de bedrijfsvoering zelf noodzakelijk is. Updates en toegang voor de leverancier vallen daar naar mijn mening niet onder.

En als er echt nood aan de man is, kan een interne echt wel even het e.e.a. aan updates downloaden en installeren. Of een websessie opzetten die de desktop overneemt.

[wizl]

En als er echt nood aan de man is, kan een interne echt wel even het e.e.a. aan updates downloaden en installeren. Of een websessie opzetten die de desktop overneemt.

Zelfs dat laatste is niet bespreekbaar Er moet iemand op locatie komen. Dat deel begrijp ik dus niet. Vaak kan ik bij calamiteiten sneller een oplossing bieden met alle tools/middelen/collega's hier dan als ik met mijn notebookje op locatie ben (die ik dan overigens ook niet in het netwerk mag hangen )

Ik snap dat het allemaal haken en ogen heeft, maar met een beetje goede wil van beide kanten is het risico anno 2009 toch behoorlijk te beperken?

[hufkes]

Gewoon een kwestie van duidelijk communiceren wat je daardoor niet kunt, blijven ze bij hun standpunt dan is het overduidelijk not done, moet je er heen, kun je geen snelle oplossingen garanderen en stuur je een vette rekening per keer dat het voorkomt. Als na een tijdje blijkt dat het te vaak voorkomt, dan zal de klant vast wel een oplossing willen zoeken, zo niet dan kost het ze gewoon per keer dat er iets aan de hand is extra geld.

Sim-pel toch?

Oh en als het niet mogelijk is een vette rekening te sturen, dan had je beter moeten testen

[ Voor 9% gewijzigd door hufkes op 12-03-2009 16:44 ]

[Verwijderd]

wizl schreef op donderdag 12 maart 2009 @ 16:37:
[...]

Zelfs dat laatste is niet bespreekbaar Er moet iemand op locatie komen. Dat deel begrijp ik dus niet. Vaak kan ik bij calamiteiten sneller een oplossing bieden met alle tools/middelen/collega's hier dan als ik met mijn notebookje op locatie ben (die ik dan overigens ook niet in het netwerk mag hangen )

Ik snap dat het allemaal haken en ogen heeft, maar met een beetje goede wil van beide kanten is het risico anno 2009 toch behoorlijk te beperken?

Als alles is dichtgetimmerd kost het vaak meer tijd en geld om de boel voor jullie open te zetten (als je het veilig wilt doen) dan jullie over laten komen.

@motrax; meerdere applicaties op een omgeving laten draaien van verschillende leveranciers is echt het domste wat je kunt doen. Dan kun je nog beter de boel open zetten. Zeker als het gaat om een dergelijk kritisch systeem. Verschillende leveranciers draaien verschillende versies van db's, services etc.. Dit kan onwijs met elkaar conflicteren. Vaak wordt er tijdens een update alleen getest of de software van de dergelijke leverancier werkt, niet of alle andere processen het ook nog doen..

[Motrax]

Ik heb het niet over een hobby bob server waar alles op draait, maar over de grotere bedrijven met complete serverparken. Meestal is het interne netwerk zo ingericht dat wanneer je eenmaal binnen bent er weinig beveiliging is. Je gaat niet voor elke server een firewall zetten of voor delen van je netwerk (tenzij bijvoorbeeld HR data, wat ook relatief gescheiden kan draaien). Je ERP systeem bijvoorbeeld moet kunnen communiceren met bijna je gehele landschap.

Als je dan die 100 leveranciers externe toegang geeft, betekent dat ook 100x dat ze je gehele netwerk op kunnen. Tenzij je dat natuurlijk weer dicht gaat spijkeren, maar dan moet je ook weer bijvoorbeeld rdp uitzetten, telnet etc etc voor die ene externe gebruiker. Met het risico dat er weer teveel rechten ingetrokken zijn, aangezien je toch vaak weer local admin moet zijn om updates te kunnen installeren.

[Verwijderd]

Motrax schreef op donderdag 12 maart 2009 @ 16:50:
Ik heb het niet over een hobby bob server waar alles op draait, maar over de grotere bedrijven met complete serverparken. Meestal is het interne netwerk zo ingericht dat wanneer je eenmaal binnen bent er weinig beveiliging is. Je gaat niet voor elke server een firewall zetten of voor delen van je netwerk (tenzij bijvoorbeeld HR data, wat ook relatief gescheiden kan draaien). Je ERP systeem bijvoorbeeld moet kunnen communiceren met bijna je gehele landschap.

Als je dan die 100 leveranciers externe toegang geeft, betekent dat ook 100x dat ze je gehele netwerk op kunnen. Tenzij je dat natuurlijk weer dicht gaat spijkeren, maar dan moet je ook weer bijvoorbeeld rdp uitzetten, telnet etc etc voor die ene externe gebruiker. Met het risico dat er weer teveel rechten ingetrokken zijn, aangezien je toch vaak weer local admin moet zijn om updates te kunnen installeren.

en precies daarvoor is een DMZ.. een zone tussen Inet en Lokale netwerk in...

[wizl]

Ik heb even snel een schemaatje in Visio geknutseld. Wat kan hier nu aan mis gaan? Op deze manier kunnen wij nagenoeg transparant bij de server (waarop dus alleen onze applicatie draait). Vanaf die server kunnen wij met geen mogelijkheid (toch?) het netwerk van de klant op....

[ Voor 11% gewijzigd door wizl op 10-09-2019 09:15 ]

[Verwijderd]

wizl schreef op donderdag 12 maart 2009 @ 16:53:
Ik heb even snel een schemaatje in Visio geknutseld. Wat kan hier nu aan mis gaan? Op deze manier kunnen wij nagenoeg transparant bij de server (waarop dus alleen onze applicatie draait). Vanaf die server kunnen wij met geen mogelijkheid (toch?) het netwerk van de klant op....

[afbeelding]

* jullie kunnen fouten in hun systeem maken
* hackers kunnen via jou systeem/sessie malware/backdoors plaatsen op die server
* Man in the middle attacks
* ISDN exploits (zal vast wel iets voor zijn)

(staat er echt maar 1 server in hun DMZ?)

[hufkes]

wizl schreef op donderdag 12 maart 2009 @ 16:53:
Ik heb even snel een schemaatje in Visio geknutseld. Wat kan hier nu aan mis gaan? Op deze manier kunnen wij nagenoeg transparant bij de server (waarop dus alleen onze applicatie draait). Vanaf die server kunnen wij met geen mogelijkheid (toch?) het netwerk van de klant op....

[afbeelding]

Waarom moeite doen om je gelijk te halen? Klant is koning, laat hem een beslissing maken op grond van de voor- en nadelen en pas al naar gelang zijn keuze je SLA aan. Typisch geval van de klant beslist want het is zijn netwerk, dan heb jij als leverancier maar niet alle gemakken die technisch mogelijk zijn. Jammer voor jullie maar het is niet anders, zij betalen heus de extra reis- en werk-uren dus netto wordt alleen de klant er slechter van. En natuurlijk kun je e.e.a. over en half jaartje of na de eerstvolgende keer dat je er heen moest weer voorzichtig opbrengen.

[wizl]

* Fouten in het systeem kan ik ook maken als ik op locatie ben.
* Hackers en MITM zie ik niet direct gebeuren met de terugbeloptie in de router?!? Of ben ik heel naief?
* ISDN exploits zelfde verhaal

Dit was even snel een schemaatje om aan te geven dat het volgens mij redelijk veilig (infrastructureel gesproken) kan. Los van de inspanningen die nodig zijn om het in te richten.

hufkes schreef op donderdag 12 maart 2009 @ 17:00:
[...]

Waarom moeite doen om je gelijk te halen? Klant is koning, laat hem een beslissing maken op grond van de voor- en nadelen en pas al naar gelang zijn keuze je SLA aan. Typisch geval van de klant beslist want het is zijn netwerk, dan heb jij als leverancier maar niet alle gemakken die technisch mogelijk zijn. Jammer voor jullie maar het is niet anders, zij betalen heus de extra reis- en werk-uren dus netto wordt alleen de klant er slechter van. En natuurlijk kun je e.e.a. over en half jaartje of na de eerstvolgende keer dat je heen moest weer voorzichtig opbrengen.

Dat begrijp ik ook allemaal, en daar zal het ook op uitdraaien. Ik wil er alleen achterkomen wat gebruikelijk is, en wat de overwegingen bij andere bedrijven zijn.

[ Voor 52% gewijzigd door wizl op 12-03-2009 17:01 ]

[hufkes]

wizl schreef op donderdag 12 maart 2009 @ 17:00:
* Fouten in het systeem kan ik ook maken als ik op locatie ben.
* Hackers en MITM zie ik niet direct gebeuren met de terugbeloptie in de router?!? Of ben ik heel naief?
* ISDN exploits zelfde verhaal

Dit was even snel een schemaatje om aan te geven dat het volgens mij redelijk veilig (infrastructureel gesproken) kan. Los van de inspanningen die nodig zijn om het in te richten.

Als jij daar zit, gaat er misschien wel iemand gewoon de hele tijd over je schouder heen kijken...

Als jullie product niet goed draait en je daarom persé rdp toegang moet hebben lijkt het me duidelijk dat je iets anders verkocht hebt dan wat de klant dacht. Als je je software vertrouwt en het kan gewoon draaien zonder problemen, dan is er geen vuiltje aan de lucht. Plan gewoon een jaarlijks onderhoud in en voor ernstige troubles ga je rijden en tikt de meter.

Ik vindt "doordrammem" om toegang ook getuigen van gebrek aan vertrouwen in je eigen product!

[wizl]

Dat is wel heel kort door de bocht. De klant kan namelijk ook gewoon fouten maken.... En die zien ze graag zo snel mogelijk weer 'achterom' opgelost

[hufkes]

wizl schreef op donderdag 12 maart 2009 @ 17:06:
Dat is wel heel kort door de bocht. De klant kan namelijk ook gewoon fouten maken.... En die zien ze graag zo snel mogelijk weer 'achterom' opgelost

Dat kun jij wel denken, maar zij blijkbaar niet, toch?
"Achterom" oplossen is wellicht niet wat ze van een serieuze leverancier verwachten. En wanneer de boel door gebruikersfouten in de soep loopt, hebben jullie het oplossen daarvan naar ik aan mag nemen in de SLA opgenomen.
Kan dat remote is het sneller en goedkoper, kiezen ze voor veiligheid dan duurt het langer en is het duurder.

En reken er op dat een keer een goede gebruikersfout (die niet stiekum toch te wijten is aan het systeem) er voor zorgt dat de gebruikers een stukje voorzichtiger met het systeem om zullen gaan. Zeker wanneer er een factuur van €1000+ gestuurd wordt om het op te lossen.

[ Voor 21% gewijzigd door hufkes op 12-03-2009 17:12 ]

[wizl]

Okay een en ander is me duidelijk. Ik denk er zelf misschien iets te lichtvoetig over. Laat ik het dan omdraaien.
Er van uitgaande dat er van allerhoogste hand is beslist dat de/een leverancier toegang krijgt. Wat zou voor jullie dan een acceptable vorm zijn? Ik ben eens benieuwd met welke constructies jullie komen

Ik zou ook nog graag weten of iemand serieuze gaten kan schieten in het schema dat ik eerder heb gepost. De ISDN verbinding mag je vervangen voor een VPN of wat dan ook. Het idee is dat de klant de garantie heeft dat de leverancier uitsluitend toegang heeft op die ene server. En van daaruit ook dus niet verder het netwerk op kan. De server kan namelijk een verbinding naar het LAN van de klant niet initiëren.

[ Voor 39% gewijzigd door wizl op 13-03-2009 09:46 ]

[tc982]

En een programma zoals netviewer/teamviewer. waar de klant zelf de sessie moet initieren en kan meekijken? Deze gaan gewoon over https naar buiten en kan dus bijna bij alle klanten gebruikt worden! Dan moet er niets specifiek openstaan en het is altijd de klant die het initieerd

[wizl]

Netviewer/LogMeIn gebruiken we ook. Kun je me (technische) argumenten geven waarom dit soort verbindingen absoluut veilig zijn?

[Croga]

wizl schreef op vrijdag 13 maart 2009 @ 09:43:
Ik zou ook nog graag weten of iemand serieuze gaten kan schieten in het schema dat ik eerder heb gepost. De ISDN verbinding mag je vervangen voor een VPN of wat dan ook. Het idee is dat de klant de garantie heeft dat de leverancier uitsluitend toegang heeft op die ene server. En van daaruit ook dus niet verder het netwerk op kan. De server kan namelijk een verbinding naar het LAN van de klant niet initiëren.

Je gaat de klant dus op kosten jagen en zijn infrastructuur laten compliceren om dit voor elkaar te krijgen? Overbodige DMZs introduceren om iets te bewerkstelligen wat ze eigenlijk al niet willen?

Als jullie product goed is gaat onderhoud op locatie ze vele malen minder kosten dan het opzetten en onderhouden van een complexe systeem structuur....

[wizl]

Croga schreef op vrijdag 13 maart 2009 @ 10:20:
[...]

Je gaat de klant dus op kosten jagen en zijn infrastructuur laten compliceren om dit voor elkaar te krijgen? Overbodige DMZs introduceren om iets te bewerkstelligen wat ze eigenlijk al niet willen?

Inderdaad! Ik wil graag discussieren over het 'wat als'. Stel dat de verbinding er (om wat voor reden dan ook) toch moet komen. Wat zou dan een acceptabel niveau van beveiliging zijn? Nogmaals, ik begrijp de weerstand, en de argumenten om het niet te doen volkomen

[TrailBlazer]

Ik heb bij een heel groot bedrijf gewerkt en daar was het doodnormaal voor 3e partijen om toegang te krijgen op hun netwerk. Het was vooral belangrijk dat de eigenaar van de desbetreffende server en de 3e partij een contract ondertekenden om het een en ander juridisch af te tikken. Als dit gebeurt was werdt er gewoon een nieuwe IPSec tunnel voor je gebouwd en kon je inloggen. Wel zat er een firewall tussen de VPN router en de rest van het netwerk. Op deze firewall werd dan aangegeven welke servers en welke poorten de 3e partij mocht benaderen.
Kortom IPSec verbinding tussen jou en de klant en de klant een firewall laten neerzetten die beperkt waar je naar toe kan.

[Verwijderd]

wizl schreef op vrijdag 13 maart 2009 @ 10:10:
Netviewer/LogMeIn gebruiken we ook. Kun je me (technische) argumenten geven waarom dit soort verbindingen absoluut veilig zijn?

http://www.milw0rm.org/exploits/6326

Misschien geen 0day exploit, maar iemand die een beetje verstandig is met dit soort dingen en achter een exploit komt kan zo je hele netwerk binnendringen.. Poorten naar binnen open zetten, ook al beveilig je ze zijn NOOIT 100% veilig.

Maar zoals ik al eerder aangeef.. veiligheid != comfortabiliteit..

[wizl]

Hoe zou je hier misbruik van kunnen maken dan. Je moet dan toch al toegang hebben op de machine waarop LogMeIn draait. Er staan juist geen poorten naar binnen open. Het zijn 2 uitgaande verbindingen voor zover ik weet...

[tc982]

Verwijderd schreef op vrijdag 13 maart 2009 @ 15:41:
[...]


http://www.milw0rm.org/exploits/6326

Misschien geen 0day exploit, maar iemand die een beetje verstandig is met dit soort dingen en achter een exploit komt kan zo je hele netwerk binnendringen.. Poorten naar binnen open zetten, ook al beveilig je ze zijn NOOIT 100% veilig.

Maar zoals ik al eerder aangeef.. veiligheid != comfortabiliteit..

Logmein is een continue verbinding die aan staat. Dat is volgens mij niet de bedoeling. Een netviewer / Teamviewer / Citrix GoToAssist / Symantec WebEx zijn clients die je alleen opstart wanneer je een verbinding nodig hebt. Je moet dan ook eerst toestemming krijgen van iemand lokaal

[wizl]

LogMeIn kan ook gebruikt worden in een vorm waar pas verbinding mogelijk is na het uitwisselen van een sessiesleutel.

Waar ik (zeker in dit beveiligingsforum) erg benieuwd naar ben is HOE veilig dit soort verbindingen (Netviewer, LogMeIn etc) nu werkelijk zijn. Zijn man in the middle attacks mogelijk? Is de versleuteling waarmee deze bedrijven schermen (256bits, SSL etc.) een waarborg, of is dat ook een wassen neus?

[dontcare]

wizl schreef op donderdag 12 maart 2009 @ 16:37:
[...]

Zelfs dat laatste is niet bespreekbaar Er moet iemand op locatie komen. Dat deel begrijp ik dus niet. Vaak kan ik bij calamiteiten sneller een oplossing bieden met alle tools/middelen/collega's hier dan als ik met mijn notebookje op locatie ben (die ik dan overigens ook niet in het netwerk mag hangen )

Ik snap dat het allemaal haken en ogen heeft, maar met een beetje goede wil van beide kanten is het risico anno 2009 toch behoorlijk te beperken?

B2b e-commercy sector hier.
Reden dat wij geen externe netwerken standaard toe laten , onze klanten.
Wij moeten elk jaar een security Audit uit laten voeren en dat gebeurt dus ook bij externe die wel toegang hebben, de security van ons netwerk is namelijk ook afhankelijk van hun netwerk , dit loopt uiteraard ook in de kosten en indien bij de externe locatie de veiligheid niet goed is komen wij niet door de audit , wat klanten kost, wat geld kost , en onze uiteindelijk onze reputatie.
Daar doet een wat langer ttr weinig aan af zolang het binnen onze SLA met de klanten past.

En uiteraard geen privé laptops op het netwerk ,daar ben je toch hopelijk niet verbaast over ?
Het gaat er niet om het risico te beperken , er moet gewoon in veel sectoren geen risico zijn, en elk extern netwerk dat je toelaat is een risico.