Firewallrequests handlen ?

[Otaku19 33]

MIch würde interessieren wie bei euch benötigte Firewallfreischaltungen bestellt werden. Wir benutzen dafür spezielle Sharepointforms, allerdings lässt die Funktionalität zu wünschen übrig.

 

Es gibt zwar einige Tools die sich damit auseianndersetzen, aber meist könen sie mir einfach zu wenig oder zu viel :)

 

Mein "Wunschtool" würde folgendes bieten:

der Requester müsste bestmöglich unterstützt werden, sprich netzwerkobjekte der Firewalls sollten auswählbar sein, Subnetze sollten nur korrekt eingetragen werden können,etc. Nicht jeder Requester im Haus kennt sich damit aus

für Hosts/Netze und Objekte sollten Owner definiert werden können, diese sollten zumindest notifiziert werden wenn eine Verbindung von/zu ihren Systemen requestet wird.

Das System sollten schon vorab klären können ob die gewünschte Verbidnung nicht ohnehin schon funktioniert. Es sollte das aber aus Firewallkonfigurationen rauslesen können, nicht anhand von Requests die bereits im System sind

der gesamte Workflow sollte übersichtlich, einfach zu konfigurieren und flexibel sein.

Ich will die Möglichkeit eines 4 Augen Prinzips bei Approvals haben

 

Was ich nicht will:

autoamtisierte Konfiguration der Firewall durch das Tool

Compliancechecks zu Standards wie PCI etc die ich teuer bezahle und eh nie benötige

[Dukel 454]

Wir benutzen dafür spezielle Sharepointforms, allerdings lässt die Funktionalität zu wünschen übrig.

 

An der Funktionalität könnt ihr ja arbeiten. SharePoint ist anpassbar.

[Otaku19 33]

ja ist es prinzipiell, aber sharepoint nachsehen zu lassen ob die verbidnung schon geht wäre im Fall einer ASA im Weg noch halbwegs realisierbar...bei anderen Systemen "unmöglich".

[Dukel 454]

Dann fehlt dir die Phantasie eines SW Entwicklers ;)

 

Es sind ja 2 Punkte. Das Requesten mit Workflows und Approvals. Da Ihr schon SharePoint habt bietet sich das an.

Das andere ist das Auslesen der Firewall Konfigurationen. Da ist es egal welche Software ihr nutzt, es bedingt immer eine API für die Firewall. Und wenn es eine solche gibt geht das sowohl mit anderer Software aber auch mit SharePoint.

[Otaku19 33]

um es klar zu stellen...ich will den Sharepointmüll nimmer :) der Aufwand die gewünschten Funktionene da einzubauen ist viel zu hoch.

 

Für Checkpoint gibts keine API, da kann man sich quasi config Files holen und die "dechiffrieren", wie es auf Juniper, Fortinet oder sonstwo aussieht weiß ich nicht, ebenso nicht was beim nächsten Upgrade wieder rauskommt. Daher wäre es sicher besser sich spezialisierte Software zu nehmen. Das einpflegen aller anderen Daten ist ohnehin schon komplex genug

[DocData 85]

Ein fertiges Produkt kenne ich nicht. Viele Kunden arbeiten mit selbstentwickelten Lösungen. Da ist von Sharepoint, so wie bei dir, über Excel bis Access alles dabei. Ich habe auch mal etwas gesehen, was auf PHP/ MySQL basierte. Aber: Bei keinem ging etwas ohne Handarbeit. Also die Pflege von z.B. Subnetzen erfolgte per Hand. An Firewall-Objekte kann ich mich nicht erinnern. Im Prinzip beschränkte es sich immer auf den Dreisatz: Quelle - Ziel - Protokoll.

 

Eine REST API wäre wohl das einfachste, um an die Objekte zu kommen. Allerdings dürfte das so ein Sicherheitsloch sein, dass es niemand implementiert hat. Bitte korrigiert mich da gerne..

bearbeitet 16. Februar 2014 von DocData

[Otaku19 33]

hmmmm...dann wäre das doch die Geschäftsidee :D

[DocData 85]

Feel free... ;) Ich sehe aber das Problem, dass so eine Sache möglicherweise zu spezifisch bei vielen Kunden gehandhabt wird. Evtl. wird es was, wenn man sich an ITIL Change Management orientiert.

[Otaku19 33]

das sind doch auch nur Best Practices :)

[DocData 85]

Na ja, bei ITIL würde ich eher von einem Common Practice sprechen. Best ist es schon lange nicht mehr. ;) Jeder Laden meint sich nach ITIL aufstellen zu müssen. Teilweise komplett, teilweise nur in in bestimmten Bereichen. Teilweise werden Prozesse angepasst und eingeführt, teilweise sklavisch aus den Unterlagen übernommen, ob es passt oder nicht. Angesichts der Verbreitung würde ich daher von einem Common Practice sprechen, nicht mehr von Best Practice. Aber das sind nur meine 0,02 €. ;)