Zum Inhalt springen

Sicherheitskonzept von Unternehmensnetzen


Empfohlene Beiträge

Geschrieben

Hallo,

ein Sicherheitskonzept muss in Zusammenarbeit der Netzwerkadministratoren von Unternehmensnetzen (IT-Administratoren) und Automatisierungsnetzen (Automatisierungsingenieuren) ausgearbeitet werden. In Abstimmung wird festgelegt, für welche Anwendung bzw. an welchen Rechnern bestimmte Rechte, Programme und Prozesse notwendig sind, und wie eine sicherheitsoptimierte Netzwerkstruktur auszusehen hat.

Ansichtssache ?

Die Fa. Siemens hat zu dem Thema ein Dokument veröffentlicht:

Siemens Industry IA/DT/BT Service&Support - Automation Service, Automation Support, Simatic Service, Simatic Support, Technical Support, Technical Consulting

M.E. muss man jetzt nicht alles lesen, wenn man was dazu sagen möchte.

Auf Seite 44 in der Doku wird grafisch eine Netzwerkinfrastruktur dargestellt.

Daran kann man eigentlich schon erkennen wohin die Reise geht.

Prozess Contol Network und Control System Network sind im Bild der Automatisierungsbereich, oder anders gesagt der Fertigungs- oder Produktionsbereich eines Unternehmens.

Es geht mir hier nicht um irgendwelche Produkte, sondern um das vorgeschlagene Konzept als solches und um Eure Meinung als IT-Administratoren.

Ist aus Eurer Sicht das vorgeschlagene Konzept sinnvoll ?

Was ist schlecht ?

Was könnte man besser machen ?

Eure Meinung zu dem Thema würde mich mal interessieren.

Wenn es das falsche Forum ist, bitte verschieben.

Gruß

Eleu

Geschrieben

Absolut sinnvoll und üblich. Ich habe einige Kunden bei denen Unternehmennetzwerk und Netzwerk für die Produktion (SPS, Maschinensteuerung etc.) getrennt sind. Teilweise sind sogar Unternehmensnetze und Netze für ERP Systeme o.ä. getrennt. Je nach Sicherheitskonzept, Anforderungen des Unternehmen etc. gibt es da verschiedene Möglichkeiten.

Wichtig: Netze nicht einfach über VLANs, Routen und ACLs trennen. Am Netzwerkübergang sollte immer eine Firewall implementiert werden.

Geschrieben

Hallo und vielen Dank.

Interessant finde ich auch, dass man dann die Administration und Verantwortung der Teilnetze dem jeweiligen Fachbereich überlassen kann, obwohl das gesamte Unternehmensnetz einer gemeinsamen Firmen-Domäne angehört.

Vielleicht auch ein guter Kompromiss, der beiden Fachbereichen gerecht wird ?

Geschrieben

Was meinst du mit Domäne? Wenn du z.B. einen Verzeichnisdienst wie Microsoft Active Directory meinst: Die Hoheit darüber kann und sollte nur in Teilen den Fachbereichen übertragen werden. Kerngeschäft der Fachbereiche ist auch nicht der Betrieb der Infrastruktur. Zudem fehlt das Knowhow. Eine Trennung ist viel mehr aus Gründen der Sicherheit sinnvoll. Störeinflüsse eines Teiles sollten den anderen Teil nicht beeinflussen. Den Betrieb der Infrastruktur, ob nun unterteilt oder nicht, sollte nur eine Abteilung oder Gesellschaft übernehmen.

Geschrieben

Auf Seite 65 steht:

Prinzipiell werden getrennte Gesamtstrukturen für die Büronetzwerke und die Produktionsnetzwerke empfohlen, da der Schutz der Daten, Berechtigungen und Rechte für beide Gesamtstrukturen getrennt erfolgt, ebenso die Verzeichnisreplikation. Auch Schemaänderungen, Konfigurationsänderungen und das Hinzufügen neuer Domänen zu einer Gesamtstruktur haben nur gesamtstrukturweite Auswirkungen. Ressourcenzugriffe werden über ein- oder wechselseitige Gesamtstrukturvertrauensstellungen ermöglicht. Da jede Gesamtstruktur (Büro- und Produktion) separat verwaltet wird, steigt durch das Hinzufügen der zusätzlichen Gesamtstruktur der Verwaltungsaufwand. Gesamtstrukturvertrauensstellungen erleichtern die Verwaltung einer segmentierten Active Directory-Infrastruktur innerhalb eines Unternehmens, indem der gesamtstrukturübergreifende Zugriff auf Ressourcen und andere Objekte unterstützt wird.

Geschrieben

Ja und?! Hast du dich mal mit Active Directory beschäftigt? Weißt du was es heißt, zwei Gesamtstrukturen zu haben? Kennst du die Auswirklungen z.B. für Exchange? Scheinbar nicht.

Ich halte eine Trennung, je nach Ausgangslage und Anforderungen des Kunden, für sinnvoll. Aber: Man kann sich damit auch ganz schön die Karten legen. Wenn die Bereiche auch noch getrennt administriert werden schafft man sich zwei schöne IT-Inseln. Unter ökonomischen Gesichtspunkten ist sowas dann eine Katastrophe.

Geschrieben

Aber wenn es nur eine IT- Domänen und Netzwerkadministration gibt, wird es dann bei Problemen nicht so laufen, dass die Elektrotechnik der IT die Schuld zu schiebt und umgekehrt genauso.

Wie will man dieses Dilemma lösen, wenn man die Verantwortungsbereiche nicht trennt ?

Geschrieben
Aber wenn es nur eine IT- Domänen und Netzwerkadministration gibt, wird es dann bei Problemen nicht so laufen, dass die Elektrotechnik der IT die Schuld zu schiebt und umgekehrt genauso.

Wie will man dieses Dilemma lösen, wenn man die Verantwortungsbereiche nicht trennt ?

Das Lösen von organisationspsychologischen Fragestellungen ist nicht Aufgabe der IT.

Nocheinmal: Du musst zwischen bei der Trennung von Bereichen zwischen einer Trennung aus Sicherheitsgründen und einer Trennung aus Verwaltungsgründen unterscheiden. Wenn es einem Geschäftsbereich darum geht die von ihm genutzt IT-Infrastruktur selber zu betreuen, dann muss man das entweder über die Delegation von Rechten lösen, oder aber die Infrastruktur wird zentral betreut. Aber es kann nicht zwei vollständig gleichwertig und selbstständig laufende IT-Infrastrukturen in einem Unternehnmen geben. Das gibt auf Dauer nur Probleme und ist ökonomisch extrem schlecht. Wenn es die Aufgabe eines Service- oder Costcenter ist die IT-Infrastruktur zu betreiben, dann hat es auch die Verantwortung dafür. Wenn du die Bereiche trennst und zwei total separate Infrastrukturen baust, dann fängt das Fingerpoint erst Recht an. Dazu kommen halt die üblichen technischen Probleme wie, wenn du schon bei Microsoft Active Directory bist, wie Hoheit über Vertrauensstellungen, Mailversand, zwei getrennte Exchange-Organisationen etc. Totaler Blödsinn also. Entweder delegiert man Rechte innerhalb der Infastruktur an den Geschäftsbereich, wenn der unbedingt etwas selber machen will, oder es gibt ein zentrales Service- oder Costcenter und das hat die Hoheit über die gesamte Infrastruktur und die Geschäftsbereiche haben nur über zentrale Gremien wie Ausschüsse oder Räte "Gewalt" über die zentrale IT.

Geschrieben

Okay, mag sein das man das so sehen muss.

Ich bin dann aber der Meinung, man sollte Visualisierungs-Rechner erst gar nicht in einer Domäne mit aufnehmen.

Nicht aus Gründen der Sicherheit, oder der Verwaltung, sondern mehr so aus Gründen der Verfügbarkeit.

Wenn ich mir vorstelle, ein Visu. - Rechner verliert sporadisch die Verbindung zur SPS, weil es einen Timeout bei der Namensauflösung gibt und ich noch nicht mal weiß in welchen Gebäude der DNS Server steht, na dann prost Mahlzeit...

Der Automatisierungstechniker der da ran muss tut mir jetzt schon leid.

Wahrscheinlich hängt der dann in einer Telefon -Warteschleife beim Versuch das Domänenkennwort über die Service- oder Costcenter- Hotline in Singapur zu erfragen.... So um 3:00 Uhr nachts.

Freitod nicht ausgeschlossen.

Ich hoffe Du nimmst mir diesen kleinen Spass jetzt nicht übel.:D

Geschrieben

Wenn ich mir vorstelle, ein Visu. - Rechner verliert sporadisch die Verbindung zur SPS, weil es einen Timeout bei der Namensauflösung gibt und ich noch nicht mal weiß in welchen Gebäude der DNS Server steht, [...]

Ich denke in so einem Fall sollte der DNS redundant abgesichert sein und man kann den Rechnern die die DNS Auflösung zu der SPS brauchen einen eigenen DNS geben. Das sind die technischen Argumente, somit trifft das Argument von bla!zilla hier genau zu

Geschrieben

In der Praxis würde ich den Fehler für den Kommunikationsabbruch erst mal woanders suchen.

Z.B. im Anwenderprogramm der SPS oder in den Kommunikationseinstellungen der Visu.

Wenn der Fehler sporadisch aufläuft, hat man sowieso ganz schlechte Karten.

Ich denke in so einem Fall sollte der DNS redundant abgesichert sein und man kann den Rechnern die die DNS Auflösung zu der SPS brauchen einen eigenen DNS geben. Das sind die technischen Argumente, somit trifft das Argument von bla!zilla hier genau zu

Wenn man diese Notwendigkeit erkennt und diese Kosten auch dafür in die Hand nimmt, dann kein Problem

Geschrieben

Wenn man diese Notwendigkeit erkennt und diese Kosten auch dafür in die Hand nimmt, dann kein Problem

Naja aber das ist die Diskussion bezüglich Organisation. Wenn ich "hochverfügbar" sein möchte, dann muss ich eben einen gewissen technischen Aufwand betreiben, der nun mal Kosten verursacht. Will ich die Kosten nicht haben, dann kann ich das technisch nicht realisieren, damit habe ich eben keine "Hochverfügbarkeit" und eben alle Konsequenzen, die daraus resultieren.

Letztendlich ist das die Fragestellung, was bin ich als Unternehmen bereit in meine IT zu investieren bzw wie teuer wird es, wenn ich Ausfälle habe. Wenn eine SPS gesteuerte Produktsanlage still steht, weil der DNS hinüber ist, wirkt sich das nun mal auf meinen Umsatz aus.

Geschrieben

Verfügbarkeit lässt sich steigern, natürlich gegen Einwurf beliebig vieler kleiner und großer Münzen.

Es ist ein wenig ironisch zu sehen das ausgerechnet Siemens sich zum Thema Sicherheit auslässt, und dann auch noch ausgerechnet bei SPS etc., wo Siemens doch selber Installationen vornimmt, wo Defaultkennwörter etc. enthalten sind, die dann auch nicht geändert werden dürfen. :rolleyes:

Ich habe einige Kunden aus dem produzierenden und technischen Gewerbe (z.B. Energieversorger, Pharma-/ Chemieunternehmen) die natürlich auch Maschinensteuerungen einsetzen. Du kannst Mängel in der "Verfügbarkeit" nicht durch die Trennung von Bereichen kaschieren. Komischerweise ticken Maschinenbauer und SPSler ganz komisch. Wollen alles selber machen, können aber nichts richtig machen. Wenn ich unmanaged Switches an Hutschienen sehe, dann brauche ich mich mit denen gar nicht weiter über Netzwerkmanagement und Verfügbarkeit unterhalten. Die sollten sowas einfach Leuten überlassen, die sich damit auskennen. Glücklicherweise gibt es immer wieder Ausnahmen die entweder Ahnung haben, oder aber zugeben keine Ahnung von IT zu haben (IT ist für Maschinenbauer auch nur ein Mittel zum Zweck), sich dann aber auch helfen lassen wollen. Siemens ist bei sowas leider nicht immer als gutes Beispiel. Und da habe ich mehr als ein Beispiel für. :rolleyes:

Geschrieben
Komischerweise ticken Maschinenbauer und SPSler ganz komisch. Wollen alles selber machen, können aber nichts richtig machen.

Das ist ein Vorurteil.

Letztendlich ist das die Fragestellung, was bin ich als Unternehmen bereit in meine IT zu investieren bzw wie teuer wird es, wenn ich Ausfälle habe. Wenn eine SPS gesteuerte Produktsanlage still steht, weil der DNS hinüber ist, wirkt sich das nun mal auf meinen Umsatz aus.

Was hilft mir denn diese Erkenntnis, wenn ich im Supportfall den Fehler nicht finden kann ?

Eines ist doch klar, wenn ich Zugriff auf alle Komponenten habe (Hard und Software) und es ist keine black box darunter (Switch, DHCP, DNS, Domäne usw.) würde ich erfahrungsgemäß den Fehler besser und auch schneller finden.

Nach diesen Kriterien werde ich z.B. beurteilt.

Geschrieben

Was hilft mir denn diese Erkenntnis, wenn ich im Supportfall den Fehler nicht finden kann ?

Dieser Erkenntnis kann ich für statistische Modellierung nehmen, d.h. ich kann sehr genau ausrechnen, ob es sinnvoll ist eine gewisse Hardware anzuschaffen. Systemausfälle kann ich empirisch auswerten und diese in ein statistisches Modell packen, so dass ich sehr wohl ausrechnen kann, ob und wie eine Veränderung der Infrastruktur sich auf die Ausfälle auswirkt.

Letztendlich ist die Frage zu klären, wie die Verfügbarkeit des Gesamtsystem korreliert mit dem eingesetzten Kapital.

Geschrieben (bearbeitet)
Das ist ein Vorurteil.

Leider nein. Das habe ich leider oft genug live erlebt. Aber ich gebe gerne zu: Es gibt ein paar Ausnahmen.

Was hilft mir denn diese Erkenntnis, wenn ich im Supportfall den Fehler nicht finden kann ?

Eines ist doch klar, wenn ich Zugriff auf alle Komponenten habe (Hard und Software) und es ist keine black box darunter (Switch, DHCP, DNS, Domäne usw.) würde ich erfahrungsgemäß den Fehler besser und auch schneller finden.

Ist das so?! Kannst du das belegen? Für mich klingt das eher nach einer Ausrede. Wenn du Maschinenbauer und ich IT-Abteilung bin, dann stelle ich dir "Schnittstellen" bereit. Du sagt mir "Ich brauch vier A-Records im DNS für die Systeme x, y und z", dann bekommst du die. Wenn du sagst "Ich brauche vier 100 Mbit TP-Anschlüsse im VLAN xyz und sechs IP-Adressen im Bereich x.y.z", dann bekommst du die natürlich auch. Wenn du dann zwei Systeme nicht erreichst, dann musst du einen Fehler in deiner Anlage ausschließen. Wenn du das kannst, dann muss es an "meiner" Infrastruktur liegen. Du nutzt Services, die dir die IT-Infrastruktur bereitstellt. Lustigerweise impliziert deine Aussage

Eines ist doch klar, wenn ich Zugriff auf alle Komponenten habe (Hard und Software) und es ist keine black box darunter (Switch, DHCP, DNS, Domäne usw.) würde ich erfahrungsgemäß den Fehler besser und auch schneller finden.

nur, dass du eben einen Fehler in deiner Anlage nicht ausschließen kannst, ohne Zugriff auf andere Systeme zu haben. Warum nicht? Nenn mir bitte Beispiele. Ich kann diesen Gedankengang nicht nachvollziehen. In meinen Augen brauchst du keinen Zugriff auf die Infrastruktur.

Um hier noch mal den Bogen zu dem Dokument von Siemens zu bekommen: IMHO ist das einfach der Versuch eine IT-Insel zu schaffen. Das wird auch in der Praxis oft genug gemacht. Leider wird bei sowas viel zu selten die IT-Abteilung mit ins Boot geholt. Stattdessen werden unter dem Deckmantel der "Anlagentechnik" IT-Inseln geschaffen was administrativ und kostentechnisch absolut unnötigt ist. Man spart sich damit nur viele Diskussionen, Abstimmungen und Konzepte. Ein Satz, bei dem sich mir die Nackenhaare sträuben:

Dies führt in letzter Konsequenz dazu, dass selbst ein virenverseuchter Computer nicht

sofort automatisch abgeschaltet werden darf, wenn dadurch die Kontrolle über den

Produktionsprozess verloren gehen würde.

Da stellen sich direkt ein paar Fragen: Warum ist die Kisten virenversucht? Wie kam der Virus in die Anlage? Warum verwendet man dort ein anfälliges System? Um es ein wenig ketzerisch zu sagen: In dem Fall muss man das Netzwerk zur Maschinensteuerung nicht vor der IT-Abteilung schützen, sondern die IT-Infrastruktur und den Rest des Netzwerkes vor den Maschinenbauern...

Bearbeitet von DocInfra
Geschrieben
Wenn du dann zwei Systeme nicht erreichst, dann musst du einen Fehler in deiner Anlage ausschließen. Wenn du das kannst, dann muss es an "meiner" Infrastruktur liegen. Du nutzt Services, die dir die IT-Infrastruktur bereitstellt. Lustigerweise impliziert deine Aussage

nur, dass du eben einen Fehler in deiner Anlage nicht ausschließen kannst, ohne Zugriff auf andere Systeme zu haben. Warum nicht?

Wenn ich deinem Ansatz folge, bedeutet es, dass ich erst in den mir freigegeben Systeme nach dem Fehler suchen muss und nur wenn ich dann da nichts finden kann, kann ich ja mal bei der IT anfragen.

Du übersiehst hierbei nur den Umstand, dass ich dann sehr viel länger dazu benötige den Fehler zu finden.

Ich kenn da ne Menge Leute bei uns, die mir dann ganz schnell ausrechnen was 15 min Produktionsausfall kosten.

Nenn mir bitte Beispiele.

In einem HMI - System ist es neben der Anlagendarstellung und Bedienung auch möglich

über SNMP Variable, Traps etc. Zustände der Netzwerkinfrastruktur zu analysieren und darzustellen.

Das Ganze, um im Fehlerfall vor Ort nicht lange danach suchen zu müssen, sondern um schnell darauf zu reagieren zu können...

Mittlerweile wird im Feldbus - Bereich das Profibus-DP immer mehr von Profinet I/O verdrängt.

Hierbei kann die TCP-IP und RT-Kommunikation über eine gemeinsame Ethernet Leitung verwendet werden.

Hätte ich Zugriff auf einen Switch könnte ich z.B. einen Mirrorport einrichten und mit einem Netzwerksniffer den Datenverkehr analysieren und überwachen.

Oder mit einer Mangement Software sogar MAC -granular den Ausfall eines Netzwerkteilnehmers.

Hier mal ein Link mit einem Beispiel was es so mittlerweile alles gibt bei den Maschinenbauern:

Siemens Industry IA/DT/BT Service&Support - Automation Service, Automation Support, Simatic Service, Simatic Support, Technical Support, Technical Consulting

In meinen Augen brauchst du keinen Zugriff auf die Infrastruktur.

Gegenfrage: Warum denn nicht ? Bin ich nicht würdig, oder wie muss ich das verstehen ????

Ob ein Visualisierungs - bzw. Automatisierungssystem einer Domäne angeschlossen werden muss, muss ich glücklicherweise nicht entscheiden. Wenn das bei uns mal so eingeführt wird, werde ich danach arbeiten. Empfehlen werde ich es aufgrund der hier gemachten Aussagen auf keinen Fall, insofern man mir die Administration über die eingesetzten Systeme verwehrt.

Geschrieben
Wenn ich deinem Ansatz folge, bedeutet es, dass ich erst in den mir freigegeben Systeme nach dem Fehler suchen muss und nur wenn ich dann da nichts finden kann, kann ich ja mal bei der IT anfragen.

Du übersiehst hierbei nur den Umstand, dass ich dann sehr viel länger dazu benötige den Fehler zu finden.

Warum benötigst du dann länger? Kennst du deine Anlage nicht? Wenn du ein Problem mit der Namensauflösung hast, brauchst du in deiner Anlage nicht viel zu testen um festzustellen, dass es ein Problem mit den DNS Servern gibt.

Ich kenn da ne Menge Leute bei uns, die mir dann ganz schnell ausrechnen was 15 min Produktionsausfall kosten.

Die kenne ich auch. Die rechnen dir dann aus, was ein virenverseuchter Rechner kostet, der ein ganzes Netzwerk infiziert aber nicht abgeschaltet werden darf, weil es ja ein Steuerungsrechner ist.

In einem HMI - System ist es neben der Anlagendarstellung und Bedienung auch möglich über SNMP Variable, Traps etc. Zustände der Netzwerkinfrastruktur zu analysieren und darzustellen.

Das Ganze, um im Fehlerfall vor Ort nicht lange danach suchen zu müssen, sondern um schnell darauf zu reagieren zu können...

Mittlerweile wird im Feldbus - Bereich das Profibus-DP immer mehr von Profinet I/O verdrängt.

Hierbei kann die TCP-IP und RT-Kommunikation über eine gemeinsame Ethernet Leitung verwendet werden.

Hätte ich Zugriff auf einen Switch könnte ich z.B. einen Mirrorport einrichten und mit einem Netzwerksniffer den Datenverkehr analysieren und überwachen.

Oder mit einer Mangement Software sogar MAC -granular den Ausfall eines Netzwerkteilnehmers.

Warum musst du dir einen Mirrorport einrichten? Warum nicht die Anforderung "Mirrorport" stellen und einen fest definierten Mirrorport von allen Ports der Anlage bekommen? SNMP Readaccess auf Komponenten kann man auch bekommen. Kann man als Service bereitstellen, sofern die Anforderung gestellt wird.

Gegenfrage: Warum denn nicht ? Bin ich nicht würdig, oder wie muss ich das verstehen ????

Du bist Dienstleister. Du nutzt eine dir zur Verfügung gestellte Infrastruktur. Warum solltest du dann darauf Zugriff haben? Vor allem auf so sicherheitsrelevate Dinge wie Switches oder gar das Kennwort des Domänen-Administrators?? Was du innerhalb deiner Anlage machst ist dir überlassen. Aber spätestens an der Schnittstelle zum Unternehmensnetzwerk ist Schluss für dich.

Geschrieben (bearbeitet)

Was du innerhalb deiner Anlage machst ist dir überlassen. Aber spätestens an der Schnittstelle zum Unternehmensnetzwerk ist Schluss für dich.

Die Fa. Siemens hat das erkannt und wahrscheinlich auch deshalb diese Empfehlung veröffentlicht.

Ich denke, ein Technologieunternehmen dieser Größenordnung, kann es sich nicht leisten, nur aus ideologischen Gründen getrennte Gesamtstrukturen für die Bereiche zu empfehlen.

Es geht in dem Dokument doch auch gerade um den Aspekt der Sicherheit ?

(Übrigens in einem PLT-System werden selten E-Mail versendet. Das macht man dann eher mal am Büro - Domänen Client)

Auf der einen Seite bemängelst Du, dass es ökonomisch extrem schlecht ist,

zwei gleichwertig und selbstständig laufende IT-Infrastrukturen in einem Unternehmen zu haben.

Auf der anderen Seite aber forderst Du von den Unternehmen die Verfügbarkeit zu steigern, natürlich gegen Einwurf beliebig vieler kleiner und großer Münzen.

Ich denke weitestgehend voneinander unabhängige Systeme sind die beste Verfügbarkeit.

Es gibt doch ohnehin unterschiedliche Anforderungen an die Netzwerktechnik in den jeweiligen Fachbereichen ?

Finde ich zumindest..

Bearbeitet von Eleu
Geschrieben (bearbeitet)
Die Fa. Siemens hat das erkannt und wahrscheinlich auch deshalb diese Empfehlung veröffentlicht.

Ich denke, ein Technologieunternehmen dieser Größenordnung, kann es sich nicht leisten, nur aus ideologischen Gründen getrennte Gesamtstrukturen für die Bereiche zu empfehlen.

Sorry, aber in meinen Augen hat Siemens gar nichts erkannt. Per Default unsichere SPS Installationen (habe ich selber bei Kunden gesehen...) und Rechner, die trotz Virenbefall nicht abgeschaltet werden dürfen, zeugen nicht gerade von einem verinnerlichten Sicherheitsverständnis.

Auf der einen Seite bemängelst Du, dass es ökonomisch extrem schlecht ist,

zwei gleichwertig und selbstständig laufende IT-Infrastrukturen in einem Unternehmen zu haben.

Korrekt. Daher stellt man Schnittstellen für die Maschinensteuerung bereit.

Auf der anderen Seite aber forderst Du von den Unternehmen die Verfügbarkeit zu steigern, natürlich gegen Einwurf beliebig vieler kleiner und großer Münzen.

Korrekt. Daher betreibt man auch nicht nur einen Domaincontroller, wenn man Microsoft Active Directory nutzt, sondern mehrere. Deswegen stellt man der Maschinensteuerung eine Subdomain bereit. Deswegen setzt man Firewalls zur Netztrennung ein. Die Liste lässt sich beliebig fortsetzen. Aber die Verwaltungshoheit über die Infrastruktur, die bleibt bei der zentralen IT.

Ich denke weitestgehend voneinander unabhängige Systeme sind die beste Verfügbarkeit.

Erhöht den Verwaltungsaufwand. Erhöht die Fehleranfälligkeit. Verhindert einheitliche Standards. Schafft Sicherheitslücken. Kostet Geld.

Es gibt doch ohnehin unterschiedliche Anforderungen an die Netzwerktechnik in den jeweiligen Fachbereichen ?

Warum formulierst du das als Frage? Weißt du das nicht? Natürlich gibt es unterschiedliche Anforderungen. Je besser die seitens des Fachbereiches formuliert werden, desto besser kann die zentrale IT darauf eingehen. Die meisten IT-Inseln entstehen aber weil Fachbereiche diese Definition umgehen wollen. Sie wollen maximale Flexibilität, keine Einschränkungen, egal was gut für das Unternehmen ist. Ich erlebe es leider viel zu oft das Maschinenbauer parallel ganze Infrastrukturen hochziehen und niemand etwas davon mitbekommt, da alles unter dem Deckmantel "Maschinensteuerung" läuft.

Finde ich zumindest..

Deine persönliche Meinung in allen Ehren, aber sie ist doch in meinen Augen stark durch deine berufliche Tätigkeit geprägt. Ich sehe zwei Seiten. Ich sehe deine Seite und ich sehe die Seite des Kunden. Ich stehe in der Mitte und freue mich. Ich verdiene an beiden Varianten: Bei der einen Variante, wo es eine zentrale IT gibt und an der andernen Variante, wo du deine eigene Umgebung hochziehst. Das ändert aber nichts an der Tatsache, dass aus Sicht des Unternehmens, aus Sicht der Prozesse, der Verwaltungsorganisation etc. eine zentrale IT-Infrastruktur die bessere Lösung ist.

Bearbeitet von DocInfra
Geschrieben
Warum formulierst du das als Frage? Weißt du das nicht? Natürlich gibt es unterschiedliche Anforderungen. Je besser die seitens des Fachbereiches formuliert werden, desto besser kann die zentrale IT darauf eingehen.

Wenn es um Verfügbarkeit geht, gibt es bei Siemens z.B. Switche am redundanten LWL Ring die an hochverfügbare redundante S7-400Steuerungen angeschlossen sind.

Die Visualisier, Programmier- bzw. Diagnosesoftware für diese Steuerungen und die Switche kommunizieren dann über Proprietäre Protokolle.

Hier hat man Ausfallzeiten von nur wenigen Millisekunden. STP oder RSTP ist da je nach Anwendungsfall zu langsam.

Der Standard sieht hier aber vor, dass man den Terminalbus und den Anlagenbus pysikalisch über separate NIC`s im Visu - Rechner voneinander trennt.

Es gibt jetzt hier zwei Möglichkeiten, entweder Du verzichtest auf diese Features zu Gunsten einer einheitlichen Infrastruktur, oder aber Du gehst hier einen Kompromiss ein und trennst an dieser Stelle doch ?

Alternativ könntest vielleicht noch versuchen diese Features über den gleichen Switchhersteller zu bekommen ?

Ist dann aber nicht mehr Herstellerkompatibel zu den Steuerungen.

Was also noch übrig bleibt, ist der Terminalbus mit x-Visualisierungsrechnern.

Diese Rechner wären dann an Deiner globalen Domäne angemeldet.

Wer würde jetzt die Benutzerrechte der Mitarbeiter in der Produktion verwalten ?

Macht das dann die IT oder die Produktionsleitung vor Ort ?

Nach meinem Verständnis ist das die Aufgabe der Produktion oder Produktionsleitung zu entscheiden, wer an welcher Anlage, wann wie was zu bedienen hat ?

Wer darf Bilder erstellen und programmieren ? Wer darf bedienen ?

Wer darf nur Bilder anschauen ?

Also würdest Du das der Produktionsleitung überlassen, oder ?

Übernehmt ihr dann auch den Software - Update - Service für Visu. und Programmiersoftware ?

Oder das Übertragen einer neuen Firmware in die SPS ?

Was wenn eure Domäne mal nicht so gut funktioniert, wie sie sollte ?

Z.B.: Core - Switch hat die Grätsche gemacht. Inkonsistente Daten bei der Verzeichnisreplikation.

Sollen wir dann die Produktion einstellen, weil sich dann kein MA mehr am Terminal anmelden kann ?

Oder wäre ein lokales Administrator - Benutzerkonto, auf den Visu. Rechnern für eine Notfallbedienung ein Kompromiss ?

Geschrieben
Wenn es um Verfügbarkeit geht, gibt es bei Siemens z.B. Switche am redundanten LWL Ring die an hochverfügbare redundante S7-400Steuerungen angeschlossen sind. Die Visualisier, Programmier- bzw. Diagnosesoftware für diese Steuerungen und die Switche kommunizieren dann über Proprietäre Protokolle. Hier hat man Ausfallzeiten von nur wenigen Millisekunden. STP oder RSTP ist da je nach Anwendungsfall zu langsam.

Ganz ehrlich? Sowas würde gar nicht in mein Netz kommen. Die Gefahr, dass die Kisten irgendwas komisches machen, wäre mir viel zu hoch. Es gäbe zwei Uplinks (wegen Redundanz) die an eine Firewall gehen zwecks Netzwerktrennung.

Zudem Rest was du geschrieben hast: Das sind Organisationspsychologische und verwaltungstechnische Fragen die man lösen muss. Das sind weniger technische Fragen. Sowas löst man über Subdomains im Sinne von AD o.ä.

Und noch ein Hinweis: Glaub nicht immer, dass nur die "IT" Fehler macht und das die Verfügbarkeit von Anlagensteuerungen maßgeblich von Außen beeinflusst wird. Oft legt ihr euch die Karten selber. ;) Leider oft genug erlebt. Und dann fängt auch das Fingerpointing sehr gerne an. Ich habe in meinen Jahren viele, viele Maschinenbauer gesehen und es ist statistisch signifikant: Es sind immer erstmal die anderen. ;)

Geschrieben (bearbeitet)
Glaub nicht immer, dass nur die "IT" Fehler macht und das die Verfügbarkeit von Anlagensteuerungen maßgeblich von Außen beeinflusst wird.

Das wollte ich damit nicht sagen.

Ehrlich gesagt, finde ich die IT - Technologien sehr interessant, sonst wäre ich hier nicht so oft im Forum unterwegs.

Ich würde gerne mal eine Windows Server Domäne und Netzwerkinfrastruktur für den Produktionsbereich entwerfen.

Gerne auch in Zusammenarbeit mit unserer hausinternen IT.

Man kann sicherlich viel voneinander lernen.

Bearbeitet von Eleu

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...