Reprise du message précédent :
Ah ben oui... (En même temps mon pseudo c'est mon nom donc bon...)

pis c'est ta photo en photo de profil ?

Les primes pas indiqués sur ton contrat ?
Heu c'est marqué quoi sur ta rénumération ?
Et c'est des primes ou un variable ?

Jordan Spieth -> golfeur  
Captain obvious proof (pas de red face)
 
Jet

 
Hum oui effectivement, j'avais pas en tête que tu voulais migrer à partir de l'appli déjà installée. My bad.
Donc au final je fais pareil : je récupère le .appx ou .eappx en lançant le download avec Fiddler pour intercepter l'url, et install via Powershell.
 
Par contre, il semblerait qu'on puisse aussi déployer à partir du AppManifest.xml : https://docs.microsoft.com/fr-fr/wi [...] oycmd-tool
A creuser je pense, vu que ce fichier reste dispo dans les répertoires des applis UWP installées. J'essaierai.

Je suis rassuré sur les licences Windows Server.
 
Maintenant on a des licences Data Core.
 
Tout va bien, ouf  
 
Je termine peut être demain

 
Poses-toi la question dans l'autre sens : quel est l'intérêt de désactiver cette sécurité ?
 
Et penser à patcher vos serveurs, c'est la mayrde côté client RDP. Il y a même des patchs pour XP tellement c'est la mayrde

 
Mais tu n'as aucun serveur virtuel

J'avais supprimé, t'es trop rapide...  

Bah se faire ch*** à ouvrir/fermer les ports...  

Tu répond toi même à la question, tu peux avoir des attaques latérales sur tes serveurs. La politique du "zero trust" est contraignante mais la plus simple à appliquer (dans la philosophie) :
https://betanews.com/2019/06/03/zero-trust-security/?

J'avais supprimé, t'es trop rapide...

Bah se faire ch*** à ouvrir/fermer les ports...

Et pour theperco, faut être admin du domaine pour être sur un serveur, donc il fait ce qu'il veut firewall ou pas firewall non ?

Je l'ai pas trouvé en préco anssi.

Je vais jeter un oeil ouais.

Euh, wat ?! Y'a pas que des admin du domaine sur des serveurs (déjà, hors DC, j'espère qu'il y a en a pas des masses). Mais y'a surtout l'appli qui y tourne. Les attaques, c'est pas juste des Russes en cagoule qui se connectent en rdp hein

Me semblait bien aussi

Du coup je m'étonne de ne pas le trouver en préco anssi.

Par contre, je comprends pas ce que tu entends par ne pas avoir d'admins du domaine hors DC ?
Tu veux intervenir avec un compte admin local (ou compte AD admin du serveur ou autres) et refuser l'accès/droits aux admins du domaine sur les serveurs d'applis ?

Et pour les attaques, tu penses à quoi ? Quelle angle ?
Avec le cloisonnement des réseaux, ça nous laisse "juste" les PC des admins non ? Qui selon leurs droits pourront faire sauter les règles du pare-feu du serveur attaqué.
Ou alors par les services de l'appli mais les ports seraient de toute façon ouvert sur le pare-feu local pour le besoin des utilisateurs?

On se connecte jamais avec un compte domain admin en dehors des DC

 
alors ça c'est la theorie....
 
en pratique, il en est tout autre.

C'est vrai quand tu interviens pour l'application ça non ?

Si ton boulot c'est juste de gérer le serveur, je vois pas bien ce que je vais foutre dessus en utilisateur...

D'ailleurs c'est pas dans les précos non plus  

Le principe de moindre privilège c'est dans les bonnes pratiques. De la même façon que tu te connecte pas en root sous Linux. Tu utilise un compte nominatif a faible privilèges et après, si nécessaire, tu fait une élévation.
Pour les attaques... L'actualité est pleine d'attaques qui ne fonctionnent que parceque les Fw locaux sont ouverts ou configurés n'importe comment : cryptolocker, petya, le bsod rdp, ...

Mais de quelles précos tu parles ?

Je crois qu'on nage en plein délire là  

Du coup toi tu te connectes sur tes serveurs en utilisateur simple et tu te sers de l'élévation pour administrer ton serveur ?

Pour info, mon infra a été audité par une boite de sécurité certifié et ce n'est pas remonté. Contrairement a tout le reste, dont root linux, cloisonnement, etc...

C'était déjà le cas et autant c'est utilisé pour les postes utilisateurs, autant jamais entendu pour les serveurs... Par contre, compte admin nominatif, etc...
Mais après je veux bien être en plein délire, j'avoue ne pas être au-dessus d'expert en sécurité d'où mon questionnement

Nebulios, je parle du guide hygiène de l'ANSSI, les 42 mesures.

Ah, qui est le meilleur ça faisait longtemps  

Honnêtement c'est pas du tout le but.

J'entends bien l0g4n et c'est intéressant. Après j'essaie de comprendre pourquoi non préconisé, risques, etc...
Et dans l'absolu, plus tu as de sécurité et mieux c'est... C'est pas du tout le débat... Après y'a la théorie et la pratique...

Après bah t'as certaines interventions...

Ben on peut très bien être admin d'un ou plusieurs serveurs sans être admin du domaine  

Non mais celui là c'est l'entrée de gamme. C'est pour les gens qui font pas/peu de sécu et qui doivent/veulent s'y mettre.
Après t'a les reco par situation (nomadisme numérique pour tout ce qui est remote/vpn/...; Administration sécurisée des SI pour justement les questions que tu poses; t'en a un pour Linux...).
Et une fois que ça c'est bon, y'a encore un niveau au dessus

Mon cours de sécu c'est sympa, tu te rends compte que 90% des gens font de la merde
Y'a du fric à se faire dans ce domaine

Tu veux dire, si les entreprises avaient du budget pour la sécu ?
Mais clairement, le domaine embauche. Majoritairement dans des SSII.

Bah tu bosses que celles qui se sont bien fait niqué une fois, après t'as la thune

Euh, ouai, c'est un peu romancée comme vision de la réalité. Les entreprises se font rarement trouer de bout en bout (petit souvenir de Maersk). Quand c'est le cas, c'est souvent des PME qui n'y survivent pas.

 
 
 
Le principe de moindre privilège s'applique dans les bonnes pratiques.
Mais quand je lis shinska, il l'applique :
Il dit avoir pour ses besoins de gestion de serveur un compte admin avec le niveau de sécurité suffisant et nominatif.
 
Je ne vois rien à redire sur ce point.
C'est mieux que permettre l'élévation à plein de comptes à faible privilège en les foutant sudoers sans "restrictions", comme c'est souvent le cas (le sudo sans password, euh comment dire).  
 
Franchement, je préfère une connexion directe en ssh:admin.user@monserveur vs une session ssh:user@monserveur qui dure des jours/semaines avec des sudo en plein milieu des commandes, et qui permet finalement à .
J'ai découvert cette pratique dans ma boite actuelle et c'est bien plus sécurisant par son isolation que le même compte user/admin(sudoer) pour tout.
 

Je pensais exactement à Maersk

Je me demande combien de boîtes (en %) ont des backups/archives utilisables en cas de coup dur

L'ideal c'est un bastion d'administration avec de l'enregistrement des sessions et des droits fins, de l'authent multi facteurs et de la séparation de rôle forte (équipe appli/équipe système/équipe infra/...).
Un mec qui, dès qu'il se connecte, peut faire n'importe quelle action qui nécessite des privilèges, c'est pas "sécurisant".

Bof, suffit d'avoir un DC quelque part a l'autre bout du globe à un endroit où Internet fonctionne pas tous les jours

De toute façon la bonne approche en terme de sécu c'est de faire une analyse de risque (EBIOSRM, ISO27005) et de déterminer les mesures à mettre en œuvre.

Sans connaitre le contexte, exigences et besoin en sécurité il y a éventuellement des bonnes pratiques à recommander mais difficile d'en dire plus.

Ben, on est sur HFR. Soit t'as une sécurité digne d'une centrale nucléaire, soit t'es la pire des merdes en sécu. Mais ne jamais trop tenir compte de l'environnement, oula jamais.
HFR quoi  

T'es pas une merde mais tu nages en plein délire

(Enfin moi en tout cas   )

PSSI ou rien