firewalldについて

firewalld把握の大事なところ！！！

# firewall-cmd --list-all
  public (active)
  target: default　★
  icmp-block-inversion: no
  interfaces: eth0　★
  sources: 　★
  services: cockpit dhcpv6-client ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
# 

target、interfaces、sourcesがポイント

参考URL

CentOS 7 firewalld よく使うコマンド - Qiita
マルチゾーンでFirewalldをらくらく設定 - Qiita
firewalld の target の default と REJECT の違い - ngyukiの日記

ポイント

ゾーン未定義のNICには、デフォルトゾーンが適用される

targetのdefaultとREJECTは似てるが、ICMP応答有無が異なる。(defaultは応答)

アクティブなゾーンは、interfaces or sourcesが割り当てられたゾーン

sourcesが割り当てられたゾーンはアクティブだが、rich rules or servicesが登録されてないと動作しない

sourcesが割り当てられたゾーンがインターフェースが割り当てられたゾーンよりも優先的に処理される(ホワイトリスト的な扱い)

rich ruleの書式は以下で確認

$ man firewalld.richlanguage

SSOについて

参考

SAML
【#27 SSO SAML】シングルサインオン セキュリティのお勉強 - YouTube
理解通り。

リバプロSSO
www.youtube.com
目からうろこ。

ケルベロス
www.youtube.com
わかりやすい。

Oauth2.0/OpenID Connectについて

参考

イメージ

OAuth2.0を図解してみた（解説） - YouTube
OAuthを分かりやすく解説（セキュリティ入門#7） - YouTube
OAuthとパスワード - インゲージ情報セキュリティ講座 - YouTube

踏み込む

Oauth2.0

一番分かりやすい OAuth の説明 - Qiita
OAuth 2.0 全フローの図解と動画 - Qiita
OAuth 2.0 グラントフロー - Authlete

OpenID Connect

一番分かりやすい OpenID Connect の説明 - Qiita
OpenID Connect 全フロー解説 - Qiita

理解するには

OAuth & OIDC 入門編 by #authlete - YouTube
OAuth & OIDC 勉強会 リターンズ【入門編】に関する記事一覧 - ログミー
細部仕様など
TakahikoKawasaki - Qiita

他参考

DevelopersIO 2017 基礎からの OAuth 2.0 perform by 都元ダイスケ #cmdevio2017 - YouTube
第一回 認証基盤のこれからを支えるOpenID Connect | オブジェクトの広場
OAuthの概要とそれを取り巻く環境｜【技業LOG】技術者が紹介するNTTPCのテクノロジー｜【公式】NTTPC
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone
　

ポイント

Oauth2.0は、サービス間でリソースへのアクセス権限の許可を行う仕組み

サービス間連携で必要な認証を、ID/パスワードのやりとり不要で実現

サービスはトークンにより、別サービスのデータへのアクセスが許可される。トークン取得時には認証/認可が必要。
例) 昨今のメーラーはID/PW保存しない実装がされてる。
　

認証、認可

OAuth & OIDC 入門編 by #authlete - YouTubeより引用

認可する前に、認証もされるケースが多い。
　

技術	標準化の範囲	トークン
Oauth2.0	認可	アクセストークン
OpenID Connect	認証	IDトークン

Oauth2.0

一番分かりやすい OAuth の説明 - Qiitaより引用

登場人物

標準化の範囲

OpenID Connect

一番分かりやすい OpenID Connect の説明 - Qiitaより引用

IDトークンとは？

IDトークンは、ユーザーが認証された事実と属性情報を持つ。これを、他アプリで使いまわせばSSOができる。
　

登場人物

OpenIDプロバイダーはIdP
　

標準化の範囲

Oauth2.0とOpenID Connectの関係

Oauth2.0に認証を加えたもの。
　

よくある実装

OpenID プロバイダーが認可サーバーを兼ねる

アクセストークンの失効について

OAuth アクセストークンの実装に関する考察 - Qiita
失効のリアルタイム実装は難しい。
アクセストークンの有効期限を短くするのが妥当。

KeyCloakメモ

参考

Keycloak - About
Keycloak とは？動作確認や機能、特徴などを解説 | OSSサポートのOpenStandia™【NRI】

KeyCloakとは？

OSSのIdP
Red Hat JBossプロジェクトが開発推進
Apache 2.0ライセンスで利用可能
エディションはなし？

機能概要

①SSO

シングルサインオン、シングルサインアウト機能を提供
Kerberosブリッジを利用すれば、ワークステーションへのサインインによるKeyCloakへの自動サインインも可能。

②IDブローカリングとソーシャルログイン

SNSや既存のOpenIDConnectまたはSAML2.0IDプロバイダーによるユーザー認証が可能。
管理コンソールだけで設定可能

③ユーザーフェデレーション

既存のLDAPサーバーまたはActiveDirectoryサーバーと連携したユーザー認証が可能。
RDMBS等、他のユーザー情報ストアとの連携も独自プロバイダ構成により可能。

④クライアントアダプター

KeyCloakとの連携を容易にする為の、SP向けのライブラリ。さまざまなプラットフォーム、言語向けにあり。
SAML2.0とOpenID Connect用があり。
※ SAML2.0とOpenID Connectプロトコルに標準対応してる為、他ライブラリも利用可能。

⑤管理コンソール

全側面を一元管理

機能の有効/無効化、IDブローカリングとユーザーフェデレーションの構成
SPの作成・管理、承認ポリシーの定義
ユーザーの権限やセッション管理
等

⑥アカウント管理コンソール

ユーザーの自アカウントの管理機能
プロファイルの更新、パスワードの変更、および2要素認証の設定
セッション管理、アカウントの履歴表示

⑦対応プロトコル

OpenID Connect
OAuth 2.0
SAML

⑧承認機能

ロールベースだけでなく、個別のきめ細かい承認ポリシーも管理コンソールで定義可能。

リリース状況

参考サイトから引用

Mattermostメモ

URL

Product Overview — Mattermost documentation
Team Edition vs Enterprise - #3 by tomstieger - Mattermost Discussion Forums
Self-Managed Pricing - Mattermost - Open-source collaboration, self-managed or SaaS

メモ

導入パターン

①Mattermost Team Edition

オンプレ利用可能、MITライセンスで無償利用可能

②Mattermost Enterprise Edition

オンプレ利用可能、有償

③Mattermost Cloud

クラウドのみ、有償

Mattermost Team EditionとEnterprise Editionの違い

EnterPrise機能の利用可否。

Team Editionは利用孵化。EnterPrise機能は実装されてるが、有効化する機能がない。
Enterprise Editionは利用可能。ライセンスキー投入により、EnterPrise機能が有効化される。

無償で使う場合でも、Enterprise Editionの方が良い。

EnterPrise機能が必要になった段階で、EnterPrise機能をシームレスに有効化できる。
ライセンスキーを投入せず利用しても問題なし。

Mattermost Cloud

エンタープライス機能が利用可能。以下2タイプがあり

①Mattermost Cloud Professional

SaaS

②Mattermost Cloud Enterprise

単一の顧客専用のAWSVPC内のプライベート環境にデプロイされる。
基盤のデプロイ・運用はMattermost社が専門家が実施。

Cookie実装メモ

参考

HTTP Cookieとは：超入門HTTP Cookie（1/2 ページ） - ＠IT

メモ

Webサーバとクライアント間でユーザーの状態などを維持・管理するための仕組み

　

ChromeのCookie確認画面(引用)

　

属性説明(引用)

ポイント

名前=値、属性で構成

WebサーバからSet-Cookieヘッダーで受信、クライアントはリクエスト時にCookieヘッダで送信

状態を示す情報で、無差別に送信しない実装がある

Cookie入手元サイトには送信する

送信先をドメイン/パス指定属性で制限できる

例) https://example.com/loginでCookieを得た場合

Domain=example.com

※.example.comは送信、example.com以外のドメインには送らない。

Path=/

Cookie入手元サイト全体に送る。
　

ファーストパーティーCookie

アクセスしたドメインから発行されたCookie
　

サードパーティーCookie

アクセスしたドメインとは別のドメインから発行されたCookie
例)
アクセスしたコンテンツ内の別サイトの広告から得たCookie
1サイト内で、複数サイトのデータをビューする場合など、広告以外の用途で利用される場合もあり、ブラウザで無効化すると動作しないサイトもあり。
　

Httponly属性でJavaScriptによる送信を防ぐ(セキュリティ目的)

HTTPプロトコルのCookieヘッダフィールドでのみ参照可能になる。

O365とDMARC認証

参考

スパム対策メッセージ ヘッダー - Office 365 | Microsoft Docs
DMARCとは？ | SendGridブログ
Define your DMARC record - Google Workspace Admin Help

IIJmio:送信ドメイン認証について

DMARC関連技術の紹介 | SendGridブログ

スプーフィング対策保護 - Office 365 | Microsoft Docs

DMARC 詳細仕様-2 | なりすまし対策ポータル ナリタイ

どれくらい自社ドメインがなりすまされているか、ご存知ですか? | IIJ Engineers Blog

Microsoft 365 のメール認証 - Office 365 | Microsoft Docs

ポイント

SPF、DKIM、DMARCのチェック対象ドメインの違い

認証方式	チェック対象ドメイン
SPF	エンベロープFrom
DKIM	DKIMヘッダで指定したドメイン
DMARC	Fromヘッダドメイン

DMARC認証は、以下2条件が満たされれば成功となる。

　SPF or DKIMのどちらかが成功
　成功した方(SPF or DKIM)で、アライメントチェックも成功
　SPF & DKIM両方で成功でも、DMARCがFAILになる可能性あり。