pikesaku’s blog

個人的な勉強メモです。記載内容について一切の責任は持ちません。

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がポイント

ポイント

ゾーン未定義のNICには、デフォルトゾーンが適用される
targetのdefaultとREJECTは似てるが、ICMP応答有無が異なる。(defaultは応答)
アクティブなゾーンは、interfaces or sourcesが割り当てられたゾーン
sourcesが割り当てられたゾーンはアクティブだが、rich rules or servicesが登録されてないと動作しない
sourcesが割り当てられたゾーンがインターフェースが割り当てられたゾーンよりも優先的に処理される(ホワイトリスト的な扱い)

f:id:pikesaku:20211017175105p:plain

rich ruleの書式は以下で確認

$ man firewalld.richlanguage

Oauth2.0/OpenID Connectについて

ポイント

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

 

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

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

認証、認可

OAuth & OIDC 入門編 by #authlete - YouTubeより引用
f:id:pikesaku:20211004041238p:plain
認可する前に、認証もされるケースが多い。
 

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

 

Oauth2.0

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

登場人物

f:id:pikesaku:20211004032727p:plain

 

標準化の範囲

f:id:pikesaku:20211004032925p:plain

 

OpenID Connect

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

IDトークンとは?

f:id:pikesaku:20211004033235p:plain

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

登場人物

f:id:pikesaku:20211004033323p:plain

OpenIDプロバイダーはIdP
 

標準化の範囲

f:id:pikesaku:20211004033458p:plain

 

Oauth2.0とOpenID Connectの関係

f:id:pikesaku:20211004033925p:plain

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

よくある実装

f:id:pikesaku:20211004033915p:plain

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

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

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

KeyCloakメモ

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

⑧承認機能

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

リリース状況

参考サイトから引用

f:id:pikesaku:20211003144542p:plain

Mattermostメモ

メモ

導入パターン

①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実装メモ

メモ

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

f:id:pikesaku:20211002174340p:plain
 

ChromeCookie確認画面(引用)

f:id:pikesaku:20211002173732p:plain
 
f:id:pikesaku:20211002173903p:plain

 

属性説明(引用)

f:id:pikesaku:20211002173617p:plain

 

ポイント

名前=値、属性で構成

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

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

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

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

例) https://example.com/loginCookieを得た場合

Domain=example.com

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

Path=/

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

ファーストパーティーCookie

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

サードパーティーCookie

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

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

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

O365とDMARC認証

ポイント

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

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

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

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