Si un objet est défini comme un programme, sa partie descriptive énonce que la
partie donnée sera traitée comme du code compilé, exécutable, en lecture seule.
Les seules opérations admises sur cet objet sont celles qui sont « censées » pour
un programme. Ainsi, on peut écrire au milieu d’un fichier de données, mais pas
au milieu de code compilé : le système s’y opposera. La conception en deux parties
des objets de l’AS/400 assure donc l’intégrité des données pour tous les objets
du système.
Enlevez le RPG et le support 5250, on a encore un AS/400.
La conception basée objet a d’importantes implications en matière de sécurité.
En effet, les virus informatiques pénètrent souvent dans les systèmes déguisés
en données. Une fois à l’intérieur, le virus essaie de devenir du code exécutable
pour causer des ravages. Un tel changement de caractéristiques n’est pas possible
sur l’AS/400. Si un package peut entrer dans le système en tant que données, il
gardera les caractéristiques de données à tout jamais. Pas question de changer
d’avis pour devenir du code exécutable.Les objets sont des composantes fondamentales
de l’AS/400. C’est l’une des nombreuses raisons qui valent à l’AS/400 sa réputation
en matière de sécurité et d’intégrité.
Comment déployer une démarche DevOps efficace, sécuriser ses processus de développement et maîtriser les coûts de ses infrastructures ? Les 9 et 10 décembre 2026, DEVOPS REX réunit les professionnels…
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et…