VI-Security

Hallo zusammen,

ich stehe vor der Aufgabe meine Projekte vor ungewolltem Zugriff schützen zu müssen.
Dazu habe ich auch ein VI, mit dem ich meine VIs in einem Projekt mit Passwort schütze.

Jedoch dauert diese Prozedur bei großen Projekten entsprechend lange.

Kennt jemand eine Möglichkeit einem gesamten Projekt ein Passwort zu verpassen oder vllt. sogar, dass man LV ganz sperren kann?
Ich habe auch schon den Domain Account Manager ausprobiert...da kann man über Cancel aber LV auch normal starten.

Danke für Eure Unterstützung!

Exe erstellen?!

Gruß, Jens

als weitere Erläuterung:

Auf den Messplatz-Rechnern ist jeweils LV installiert und wir arbeiten mit den compact Fieldpoint.
Im Moment könnte jeder Nutzer LV öffnen und in der Entwicklungsumgebung die PC-seitige und die Realtime-seitige Applikation ändern und starten.
Daher nützt mir die Security in der EXE nicht viel.

Hallo,

Zitat:Auf den Messplatz-Rechnern ist jeweils LV installiert

Habt ihr so viele Lizenzen?

Zitat:wir arbeiten mit den compact Fieldpoint.

Aha.

Zitat:Im Moment könnte jeder Nutzer LV öffnen und in der Entwicklungsumgebung die PC-seitige und die Realtime-seitige Applikation ändern und starten.

Wieso denn das? Wieso bekommen Nutzer eine Entwicklungsumgebung? Warum bekommen Nutzer keine Exe?

Zitat:Daher nützt mir die Security in der EXE nicht viel.

Gib deinen Nutzern Executables, dann ist alles so wie es sein sollte.

Hallo,

du kannst aber auch einfach in den VI Einstellungen unter Schutz einstellen, dass man nur mittels Passwort aufs BD zugreifen kann. Das wird den ungewollten Zugriff auf deine VIs verhindern, Zumindest aufs BD. Hoffe, dass es das ist, was du brauchst.

MfG Carsten

Danke für eure Antworten.

Auf den Mess-PCs ist LV installiert da sich bei der Inbetriebnahme der Teststände sich die Fehlersuche einfacher gestaltet.
Da wir ständig umbauen, muss ich auch ständig umprogrammieren und das schnell testen und aufspielen.
Wir haben eine Campuslizenz.

Ich habe auch schon ein VI, dass andere VIs mit nem Passwort versieht.
Die Projekte enthalten aber wenigstens 100 VIs und damit dauert es entsprechend lange diese zu locken oder zu entsperren.

Ich hab die Hoffnung noch nicht aufgegeben, dass man vllt über ein Zusatzpaket oder den Domain Account Manager eine Lösung möglich ist.

Hat jemand noch ne Idee?

Anzeige

(13.03.2012 07:30 )raeuberfisch schrieb:  Danke für eure Antworten.

Auf den Mess-PCs ist LV installiert da sich bei der Inbetriebnahme der Teststände sich die Fehlersuche einfacher gestaltet.
Da wir ständig umbauen, muss ich auch ständig umprogrammieren und das schnell testen und aufspielen.
Wir haben eine Campuslizenz.

Ich habe auch schon ein VI, dass andere VIs mit nem Passwort versieht.
Die Projekte enthalten aber wenigstens 100 VIs und damit dauert es entsprechend lange diese zu locken oder zu entsperren.

Ich hab die Hoffnung noch nicht aufgegeben, dass man vllt über ein Zusatzpaket oder den Domain Account Manager eine Lösung möglich ist.

Hat jemand noch ne Idee?

Der Domain Account Manager dient nicht um im Project Sicherheitsvorkehrungen einzubauen sondern ist eindeutig dazu da innerhalb von Applikationen ein Sicherheitssystem zu implementieren. Also zur Laufzeit Deiner Applikation Funktionen, Bedienelemente und dergleichen verfügbar zu machen oder nicht, basierend auf dem aktuel eingelogten Benützer. Theoretisch könnte man sicher ein Projektplugin schreiben dass von diesem Account Manager Gebrauch macht um niur dann Zugang zu den VIs im Project zu geben, aber das würde niemanden daran hindern die VIs nicht einfach im Explorer anzuklicken und ausserhalb des Projekts zu öffnen.

Gründsätzlich wäre wohl zu sagen, dass Du Deine Strategie überdenken solltest. Anstatt die Zeit in solche Spielereien zu stecken wäre sie meiner Ansicht besser investiert in den Aufbau eines sinnvollen Versionskontrollsystems mit daran gekoppelter Archivierung und natürlich dem Willen sich die Disziplin der Benützung eines Versionskontrollsystems zu eigen zu machen.

Wir benutzen Tortoise SVN um unseren Softwarepool zu verwalten.

Und wo liegt dann das Problem? Sind die anderen Mitarbeiter im Betrieb nicht selbstverantwortlich genug, dass wenn da einer am Code rumbasteln würde, Du dafür zur Verantwortung gezogen würdest?

Da Du Versionsverwaltung hast kannst Du jederzeit überprüfen ob der aktuelle Code noch mit dem Repository übereinstimmt, und wenn nicht, dann hat da jemand damit rumgebastelt. Und dann müsste man im Falle von sinnlosen oder gar falschen Anpassungen durch "Unbefugte" auch entsprechende Massnahmen treffen. Locken von Code innerhalb einer Firma ist meines Erachtens eine schlechte Idee. Da zieht doch hoffentlich jeder am selben Strick und wenn nicht muss man das anderswo anpacken.

Und im Falle von Operatorn die per Unglück Änderungen am Code verursachen könnten ist doch wieder auf die Executable hinzuweisen. Ein Executable Deiner Applikation bedeutet nicht, dass Du im Falle der Fälle nicht die Entwickelversion ebenfalls auf der Maschine hast und diese startest um das Debugging zu tun. Nachdem Du einmal Deine Applikation angepasst hast dass sie auch als Executable einfach läuft (das ist fast immer etwas Arbeit um ein Programm auch als Executable gut laufen zu lassen, da Dinge wie Pfadänderungen, anderes Verhalten der Betriebssystemumgebung etc. oft unvermeidbar sind), brauchst Du nach jeder Änderung nur einmal das Build Executable zu starten und das Executable liegt wieder bereit für die gewöhnlichen Operators.

Zitat:Und wo liegt dann das Problem? Sind die anderen Mitarbeiter im Betrieb nicht selbstverantwortlich genug, dass wenn da einer am Code rumbasteln würde, Du dafür zur Verantwortung gezogen würdest?

Ja, im Zweifelsfall habe ich den Ärger, da ich bei Inbetriebnahme für die Sicherheit eine Unterschrift leisten muss.

Genau so wird es auch bei uns gemacht: die exe für die gewöhnlichen Nutzer.
Doch nach mehrmaligem "nebenbei über die Schulter schauen" wissen die Nutzer auch wo die Projekte liegen und könnten in diesen sicherheitsrelevante Änderungen vornehmen und aus LV heraus starten oder auf das RealTime-System aufspielen.
Das gilt es zu vermeiden.